inheritance is when you design objects around what they are
composition is when you design objects around what they do
We design a game where we have
Dog .poop() .bark() Cat .poop() .meow()
poop function duplication we create a mother
Animal .poop() Dog .poop() .bark() Cat .poop() .meow()
Now we add more classes on a different line of inheritance
MurderRobot .drive() .kill() CleaningRobot .drive() .clean() Animal .poop() Dog .poop() .bark() Cat .poop() .meow()
Same problem as before, we need another mother class for robots
Robot .drive() MurderRobot .kill() CleaningRobot .drive() .clean() Animal .poop() Dog .poop() .bark() Cat .poop() .meow()
After a while a new needs is coming : We need a murder robot dog who can kill, drive and bark. But it cannot poop (no digestive system)
At this point, the class inheritance taxinomy is deeply wrong. We cannot put a MurderRobotDog class inside.
The only solution keeping inheritance is to set a super motherclass but children will have method they should not have in attached to them. So it is bad.
This problem is called the Gorilla Banana Problem (You request a Banana, you got a Gorilla and the entire Jungle with it).
The solution is composition (design objects around what they do)
dog = pooper + barker cat = pooper + meower cleaningRobot = driver + cleaner murderRobot = driver + killer murderRobotDog = driver + killer + barker
Lots of devs just favors composition over inheritance and some never use inheritance.
He is not saying inheritance is bad directly but if you don't use constructors you cannot use
or a code smell
In the rest of this article, I’ll explain what are those inheritance pitfalls that composition (in GoF sense) tries to avoid, and I’ll show that concatenative inheritance still carries them.
he is taking the @mpj
murderRobotDogexample adding more complexity to output this conclusion : Object composition is not object merging.