Hello Mr. Siebers,

Beside the GoF book I can also advice the books "C++ Coding Standards" by Herb Sutter and "Effectiv C++" by Scott Meyers, which also adress this issue.

As OO designer one should aim for a loose coupling of objects. Inheritance is a very strong relationship / coupling between classes as opposed to aggregation (composition). Therefor if it is possible to express a relationship between classes with aggregation rather than inheritance, do it. In other words use aggregation whenever you can and inheritance whenever you have to.

As mentioned by Herb Sutter, here are some advantages of aggregation over inheritance:

• Greater flexibility without affecting calling code.
• Greater compile-time insulation, shorter compile times. (This one is more C++ specific)
• Greater robustness and safety
• Less complexity and fragility

However there are also several cases where one has to use inheritance. Most often this is the case if the goal is substitutability. To be more concrete:

• use inheritance to model "is-a" relations
• use aggregation if you want to model "has-a" and "is implemented as a"

Basically it's all about reusing behaviour from other classes. If you want to reuse something from a class but the subclass isn't really substitutable for the base class, the usage of inheritance is wrong. However this doesn't meant it's not possible to use inheritance to reuse behaviour, but it has a lot of drawbacks as compared to aggregation. I think this is also what the GoF advice aims at. It may translate to "Use inheritance and aggregation to model the right kind of relationship."

Many thanks for your description. Very helpful!

I also did a bit of background reading and I think your translation provided at the end of your answer is very good summary (i.e. "Use inheritance and aggregation to model the right kind of relationship."). For my background reading I looked at chapter 16.3 of "Flexible, Reliable Software Using Patterns and Agile Development" which is freely available online.

http://www.baerbak.com/chap16.pdf

Another take on this - boiling down to the same thing.  http://stackoverflow.com/a/269535/838992 . Makes me consider some of my bad design decisions over the years..

I think the "is" versus "has" distinction is a nice one.

On a separate but related note, I've found that designing interfaces before any implementing code is very useful in this regard.  It generally helps (me) focus on whether a number of entities actually are specialisations of a parent type (the "is" / inheritance version), or whether they simply have a particular class of thing.

P.S. Sorry no UML ;)

@StefanGruner Thanks for your insightful response.  As you imply, my "distinction" remains loose.  I like your argument against inheritance from the type-checking angle and it is nice to see the argument backed by Dijkstra's argument types.

You are, of course, correct to assert that it is never necessary to introduce inheritance - again good to see a strong theoretical backing of that point vis-a-vis Turing completeness.

I'm not a particular fan of inheritance (despite having used it throughout my most recent project - perhaps a bad decision some years ago).  However, I can see that there are arguments (yes, convenience arguments) for using inheritance when you really want to stress the fact that all Y are a subset of X and it makes your life a lot easier to have access to the functionality that X already has (maybe pre-coded for you if we take this into the concrete example domain). 

However, I certainly agree that one should not try too hard (indeed, should strenuously avoid) turning  having intobeing a haver.  Maybe, though, your argument advises us that the benefits (in type checking and testing) mean that sometimes we should put effort into turning "being an X" into "having an X to represent the features of X, all of which I share" (my own take on your translation from inheritance to aggregation)

I believe characteristic of good design is design by composition whereby your classes are composed of other classes such as properties of a particular type. This allows for inversion of control and the ability to make software that is extensible without modification or tight coupling. Inheritance has its purpose but I too think it because difficult to maintain when you continue to extend sub classes. Eventually you get to the point where you need to start going back up the chain to add in abstract methods to support further operations. Design by composition is essentially what GOF is referring too.

For example consider you have a duck as a base class. You could create a mallard type which inherits from the duck class. But lets say that you have a method called make_sound(). If you implemented this in the base class you would define it as "Quack" and the mallard type would be able to use it.  Now you are to add a new duck of type : Rubber_Duck. The issue here is that a rubber duck does not go "quack" but may go "squeak". Now you need to override your original make_sound() method. Now you learn you need to make a variety of sounds so you need to back into the base class and rethink the entire design.

If you use an interface you could have simply defined the method of make_sound() and created many sounds that share this behavior. Then you apply the make sound type as a property into your duck class. Now you can simply assign the right type of sound at run-time to the derived type without altering your design. 

When we talk about designing a system, we are not talking about the representation of a problem in an elegant way, but it is more about how clear can we represent it in a human mind, and it is also about the simplicity of extending a system(without modifying it).

For the human mind the concept of inheritance is very intuitive, that is why it was broadly used in the first days of object oriented design. But after some years, it was clear that inheritance made classes to be highly coupled, and so this prevented the systems to be extended in a simple way (without modifying it).

That’s why it was clear that in the design of systems we should “Favor Aggregation over Inheritance”, because then it was easier to extend them.