Most people prefer compose to inherit,
but what's the significant benefit for doing so?
A:
In languages that do not support multiple inheritance, you don't 'burn' your one chance to derive from another class(type).
Also, it can be a more appropriate modelling of the problem domain.
Mitch Wheat
2010-03-11 11:56:55
Interesting article, but it actually says that inheritance is not the solution for each and every problem, rather than saying that inheritance should not be used, as the article's title implies.
OregonGhost
2010-03-11 12:12:57
yeah... it's actually pointing that using inheritance inappropriately is evil.. not really inheritance per se...
ultrajohn
2010-03-11 12:39:53
I like the mindset of the article. But I don't like the implementation in the example for several reasons. First, it's not a real implementation of the Strategy Pattern. A Strategy Pattern should proxy a common method to an aggregated objects method. Here is a much better example of how to implement the Strategy Pattern the right way: http://www.cumps.be/design-patterns-strategy-pattern/ Second, but less important to me, it gives direct access to the aggregated object with `dj.darkPowers.crushTownspeople()` which violated the Law of Demeter: http://en.wikipedia.org/wiki/Law_of_Demeter.
fireeyedboy
2010-03-11 13:01:03
dbemerlin
2010-03-11 13:16:38
A:
because the new class does not fully qualify as something the can be put under the 'inheritance' hierarchy for that particular 'base class'...
significant benefits:
the option of extending another class is 'always' available
you don't get tied down to the implementation and definition of the base class
ultrajohn
2010-03-11 12:06:32
But imho composition requires a lot more code. For inheritance you only have to overwrite what you want to change (often just 1-2 methods), with composition you have to either provide the full interface or an abstraction which would make it a "facade" or allow access to the object which violates encapsulation. OTOH i don't really see composition and inheritance as related patterns as each of them has a special use-case.
dbemerlin
2010-03-11 12:28:01
yeah, they're really different... the problem actually here is about using inheritance when not appropriate... and so on... this kind of things when get looked upon by some individuals and noticing that the inheritance is bad lead to the conclusion that the thing is indeed bad, but actually, it's just something which made use of inheritance when it's not suppose to...
ultrajohn
2010-03-11 12:38:54
A:
Inheritance is a good tool for the right situation, but is often overused.
By preferring composition to inheritance, you get a way to swap out implementations on the fly. For example, you can compose a class by giving it an interface that provides a behavior. If that class needs 2 different implementations for different situations then you have that freedom. If you had used inheritance, however, then you would still have the behavior of your super class and would have to override it in a ton of spots. Basically, composition is a far more flexible model for creating objects.
Keith Rousseau
2010-03-11 12:19:22
+3
A:
This article should give you a complete answer: Design Principles from Design Patterns: Composition versus inheritance
I quote a straight answer from Erich Gamma here:
I still think it's true even after ten years. Inheritance is a cool way to change behavior. But we know that it's brittle, because the subclass can easily make assumptions about the context in which a method it overrides is getting called. There's a tight coupling between the base class and the subclass, because of the implicit context in which the subclass code I plug in will be called. Composition has a nicer property. The coupling is reduced by just having some smaller things you plug into something bigger, and the bigger object just calls the smaller object back. From an API point of view defining that a method can be overridden is a stronger commitment than defining that a method can be called.
In a subclass you can make assumptions about the internal state of the superclass when the method you override is getting called. When you just plug in some behavior, then it's simpler. That's why you should favor composition. A common misunderstanding is that composition doesn't use inheritance at all. Composition is using inheritance, but typically you just implement a small interface and you do not inherit from a big class. The Java listener idiom is a good example for composition. With listeners you implement a listener interface or inherit from what is called an adapter. You create a listener object and register it with a Button widget, for example. There is no need to subclass Button to react to events.
Findekano
2010-03-11 12:21:27
A:
Several design patterns use compsition of an interface for which an inherited implementation is used. So composition doesn't rule out inheritance.
But using inheritance for everything tends to lead to multi-inheritance, big class hierarchies and lots of exceptions.
stefaanv
2010-03-11 12:24:21