The first one being deep inheritance trees. Those deep trees tie all the classes within a hierarchy together, so if you change one, you often have to look at the others. So avoid these. Sometimes it can be better to use composition instead of inheritance, even if inheritance would not be a logical flaw (like the fruit-salad example). So Apple would not inherit from Fruit, but instead wraps a Fruit and delegates some method calls to it. I think this really is what “Favor composition over inheritance” is about.

The second problem is what you mentioned – don’t confuse “is-a” with “has-a”. This is not what I think “Favor composition over inheritance” is about, because using inheritance if you have “has-a” relationship is not a matter of choice, but simply wrong!

Just because you as the original developer don’t see a reason why anything would need to be subclassed doesn’t mean that someone else won’t.

I’ve run into a lot of headaches before where things were needlessly private (which you can work around, but it’s not good practice) or things were marked final (which is even uglier to work around) because the original developer couldn’t read my mind :)

For similar reasons people say PHP is good (beaucse it’s so flexible, even if that flexibility comes at the cost of readability) OO is also good. It’s a loaded gun aimed right at your foot..don’t pull the trigger ;)

public function getPropertiesArray() { //or something..
return (array) $this->getProperties();
}

It would be worth for many programmers to explain it in separate article – two points are well known (inheritance vs composition and interface vs implementation), the third is very important one…

You should establish your point with the fruits then back it up with an example a php programmer is likely to actually encounter in reality. Users and User groups or CMS articles or something.

Agree with first comment about misleading title.

If the object is of DoSomeWork, then this executes DoSomeWork::runMyFunc(). If it’s a DoSomeMoreWork object with that method defined, then that method is called. The method could be defined in the BaseClass, as far as OOP is concerned. It’s actually what inheritance is about; not knowing what is the exact class, and still be able to execute a method. There is no unpredictable behavior here.

Apart from that, yes, a lot of inheritance approaches should be solved with composition.

Point taken. I don’t want to scare people away from inheritance. I want them to use it properly. Sadly, the examples I provided were dumbed-down versions of examples I’ve seen in real life code, including some major frameworks and applications. Good architecture is essential.

Yep, you’re right. I misread that class name. My bad.

But that doesn’t change my point of not scaring people from inheritance. If used properly, it doesn’t harm. And if you know what you’re doing it won’t kill anyone.

Martin, it is what inheritance is made for – if you intend for that to happen. For example, if you direct the function to return a stdClass object and you override that telling it to return an array, you might get undesired functionality.

As for extending Cherry with FruitSalad, you’d be amazed at how often I see that very mistake. Which is why I used that perhaps overly-simplified mistake – everyone can relate to the fact that a fruit salad is not made of a single fruit. On the other hand they might not be able to see that their database object isn’t in the same family as their business logic. Hopefully they’ll think about the example and give it some thought.