5

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?

Community
  • 1
Frank
  • 153
  • 1
  • 4
  • Related discussion on Stack Overflow: [Prefer composition over inheritance?](http://stackoverflow.com/q/49002/590790) – Steven Jeuris Nov 12 '12 at 17:04
  • 2
    http://programmers.stackexchange.com/questions/134097/why-should-i-prefer-composition-over-inheritance http://programmers.stackexchange.com/questions/156592/composition-vs-inheritance http://programmers.stackexchange.com/questions/65179/where-does-this-concept-of-favor-composition-over-inheritance-come-from http://programmers.stackexchange.com/questions/66879/how-do-we-know-to-favour-composition-over-generalisation-is-always-the-right-cho – pdr Nov 12 '12 at 17:51
  • If you systematically avoid inheritance everywhere, your code will not be OOP and the benefits of it will be lost on you. That being said, some people don't like OOP, and maybe that's who you're working with. – MrFox Nov 12 '12 at 18:20
  • Vote-to-closers, I don't think this is a dup, because it's not yet another inheritance vs. composition question, it is asking about a very restricted form of inheritance. – Karl Bielefeldt Nov 12 '12 at 18:25
  • @Karl - I'm also asking specifically if keeping inheritance but forbidding the use of anything but public members of the parent classes would be acceptable to people who favor composition. – Frank Nov 12 '12 at 18:36
  • @Karl: Without a specific example, the question is essentially "Is it *always* right to favour composition over inheritance?" which is also the question in my fourth link. – pdr Nov 12 '12 at 18:42
  • @pdr. No. I'm really asking about inheritance where the derived are restricted to use only public members of the parents. Would that be equivalent enough to composition? – Frank Nov 12 '12 at 18:44
  • *Would that be equivalent enough to composition?* Equivalent enough **for whom**? Inheritance and composition are different things. Relying exclusively on composition ignores a useful tool, just as relying exclusively on inheritance does. – Caleb Nov 12 '12 at 18:48
  • @Caleb see Karl's answer below. He is explaining how this solution is not equivalent to composition, what it misses from the composition approach. That's what I was looking for. – Frank Nov 12 '12 at 18:50
  • @Frank: I'm sorry. I guess I don't see what you were trying to achieve or why, but if Karl has cleared up your confusion then it's all good. – pdr Nov 12 '12 at 18:51
  • @pdr Here is the story: someone suggested we should use composition rather than inheritance at work. I found that rather radical, so I'm digging into it. I had the idea that maybe we could continue using inheritance, but never allow derived classes to access the implementation of the parent. I wanted to check how that differed from composition. Karl answered that it helps with loss of encapsulation, but still implies perfect substitutability. – Frank Nov 12 '12 at 18:58
  • 1
    @Frank: Ok, I see what you're saying, but I would strongly recommend reading all the answers to the various conversations above. You probably need to understand the benefits of composition over inheritance before you start fighting that decision. Make no mistake, it is a bad decision to completely forbid inheritance but it's also a bad decision to use inheritance before you fully understand the reasons not to. – pdr Nov 12 '12 at 19:16
  • 2
    @MrFox That's not quite true. OOP is about interfaces. Inheritance is just a mechanism that happens to be included in most OOP languages. – Doval Mar 28 '14 at 11:53

2 Answers2

11

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.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
4

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.

haylem
  • 28,856
  • 10
  • 103
  • 119
Lesstat
  • 324
  • 1
  • 3