Avoid inheritance in OOP software development?

preview_player
Показать описание
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!
Рекомендации по теме
Комментарии
Автор

Been following your channel for a while now and just wanted to say I am loving this quick answer format!

yerffej
Автор

Apparently, I already use lots of composition, and I didn't even know what it's called.

I already looked at a JS example of composition and it sounded like rocket science to me, but thankfully hearing the concept rather than an implementation in a strange language allowed me to figure it out.

What I wonder is why would anyone ever use inheritance when composition, to me, was like the "default"? I started using it without even thinking about it, and it makes much more sense coming from a coding style that mostly uses functions. It's almost like extra work to achieve the same thing.

IndellableHatesHandles
Автор

So from my experience, inheritance of data is fine, inheritance of behaviour is not

What ends up happening is you try to make 2 things the same when they look the same, but aren't exactly the same. I always think of it that humans have legs, but not all of us walk exactly the same

composition is much more extensible and agile

MikeStock
Автор

Kids, remember those two simple rules:
1) the more you inherit, the richer you are.
2) poor parents are misfortune, poor in-laws are stupidity.

MrKret
Автор

Maximum treści, minimum słów. To mi się podoba.:)

pawed
Автор

fajny odcinek, dużo merytoryki i można poćwiczyć angielskie :) zmieniłbym tylko koszulkę, zbyt obcisła, albo przypakował :D

mattkurantowicz
Автор

Quick answer needs to be played at 1.75x speed

GaryMcNeill