Alternative to "inheritance versus composition?" [duplicate]

Question

Possible Duplicate:
Where does this concept of “favor composition over inheritance” come from?

I have colleagues at work who claim that "Inheritance is an anti-pattern" and want to use composition systematically instead, except in (rare, according to them) cases where inheritance is really the best way to go.

I want to suggest an alternative where we continue using inheritance, but it is strictly forbidden (enforced by code reviews) to use anything but public members of base classes in derived classes.

For a case where we don't need to swap components of a class at runtime (static inheritance), would that be equivalent enough to composition? Or am I forgetting some other important aspect of composition?

Answer 1

You're sort of looking at it backwards. Composition isn't preferred because of some unseen benefit of composition, it's preferred because it avoids the drawbacks of inheritance. Inheritance adds the significant benefit of substitutability. However, that benefit comes with the significant cost of tight coupling. Inheritance is the strongest coupling relationship possible. If you don't need the substitutability, the coupling cost isn't worth it.

Your restricted version of inheritance addresses its other cost, a loss of encapsulation, but does nothing about the much more significant cost of coupling.

Answer 2

I think the difference between the two things is in their intent. Is the class you are writing really meant to be used as replacement / specialisation of its Base class or is it just using some functionality? If the First Case is true you should go with inheritance. If the latter is true go for composition. In my experience using inheritance where composition would be appropriate creates a more complex, less understandable and meanigful codebase.