Inheritance key feature of OOP. It’s very important to know exactly how it works and what you can do with it. I’m sure you’re pretty familiar with the subject already. So I’m sure you know all the cases where it’s useful, but what about the opposite? When you should avoid inheritance in software development?

#programming #tech #softwaredevelopment #quickanswer

Obviously you’ll want to use inheritance in all object-oriented languages, C++, C#, Java, Go… Wait. No, Go is a no-go, it doesn’t have inheritance. Anyways - some languages support object oriented paradigm fuller than others. C++ for example offers multiple inheritance. That’s right - every class can have multiple parents. Standard even says that every compiler has to support at least 1024 parents.
Quick Reminder: Inheritance extends a class with new fields and methods by creating a child from chosen class. This child has a new name, and “inherits” all properties from its parent. Think of it as embedding a parent class into its child.
Now, as programmers we often write new classes, and sometimes - it’s time to make a choice: should these two classes be related and how? There are some commonly known rules that’ll help you decide, and also some less commonly known rules. I’ll cover both, so stay with me.
So, two classes are definitely connected, but are they connected via inheritance or composition? (Composition is when one class has a field with a reference to an object of another class). In this case we’ll follow the Is-A-Has-A relationship guideline. Say that we have a few classes: Star, Color and Shape. Star Is-A Shape, so it could be an inheritance relationship, but Star HAS-A Color, so it’s a composition. Shape is not-a Color, but maybe could have-a color if we’d be so inclined. Another very common example has a Car, Truck and Engine classes - can you arrange these in possible hierarchies?
Okay, I’ve mentioned the basic common rules - what is that less known, more insightful reason to avoid inheritance? Gang of Four, or fathers of design paradigms call inheritance a white-box reuse, that all the implementation details of the parent class are visible to the child. While composition is called black-box reuse - each class’s implementation is closed, encapsulated from another.
Encapsulation as we know is another key feature of OOP, and when one class inherits from another - parent class gives up part of its encapsulation to create child class. This has good and bad sides: it’s easier to write such a child class. However, (and this is important) things might get tricky, when you’ll try to change the representation or implementation of the parent class. Because it’s so easy to depend on a parent - most child classes will.
Other issue is the permanent nature of such a relation: inheritance is forever: when you decide on a child class in compile-time, you won’t be able to change it runtime, you will have to destroy an object and create another, unlike a composition, where you can swap and switch however you like.
By leveraging composition we also achieve two other things. One: we follow another important rule of clean code: single responsibility. If a class inherits from too many parents - most likely it no longer serves a single purpose. Two: our code complexity metric called Depth of Inheritance Tree (or DIT for short) will remain low. Too complex code is a nemesis of every programmer. Staying vigilant will help you and your colleagues get more quality sleep at night.
Subscribe, and I’ll see you in the next one, cheers!