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

Question

In the last few months, the mantra "favor composition over inheritance" seems to have sprung up out of nowhere and become almost some sort of meme within the programming community. And every time I see it, I'm a little bit mystified. It's like someone said "favor drills over hammers." In my experience, composition and inheritance are two different tools with different use cases, and treating them as if they were interchangeable and one was inherently superior to the other makes no sense.

Also, I never see a real explanation for why inheritance is bad and composition is good, which just makes me more suspicious. Is it supposed to just be accepted on faith? Liskov substitution and polymorphism have well-known, clear-cut benefits, and IMO comprise the entire point of using object-oriented programming, and no one ever explains why they should be discarded in favor of composition.

Does anyone know where this concept comes from, and what the rationale behind it is?

Answer 1

Though I think I've heard composition-vs-inheritance discussions long before GoF, I can't put my finger on a specific source. Might have been Booch anyway.

<rant>

Ah but like many mantras, this one has degenerated along typical lines:

1. it is introduced with a detailed explanation and argument by a well-respected source who coins the catch-phrase as a reminder of the original complex discussion
2. it is shared with a knowing part-of-the-club wink by a few in-the-know for a while, generally when commenting on n00b mistakes
3. soon it is repeated mindlessly by thousands upon thousands who never read the explanation, but love using it as an excuse not to think, and as a cheap and easy way to feel superior to others
4. eventually, no amount of reasonable debunking can stem the "meme" tide - and the paradigm degenerates into religion and dogma.

The meme, originally intended to lead n00bs to enlightenment, is now used as a club to bludgeon them unconscious.

Composition and inheritance are very different things, and should not be confused with each other. While it is true that composition can be used to simulate inheritance with a lot of extra work, this does not make inheritance a second-class citizen, nor does it make composition the favorite son. The fact that many n00bs try to use inheritance as a shortcut does not invalidate the mechanism, and almost all n00bs learn from the mistake and thereby improve.

Please THINK about your designs, and stop spouting slogans.

</rant>

Answer 2

Experience.

Like you say they are tools for different jobs, but the phrase came about because people were not using it in that way.

Inheritance is primarily a polymorphic tool, but some people, much to their later peril, attempt to use it as a way of reusing/sharing code. The rationale being "well if I inherit then I get all the methods for free", but ignoring the fact that these two classes potentially have no polymorphic relationship.

So why favour composition over inheritance - well simply because more often than not the relationship between classes is not a polymorphic one. It exists simply to help remind people to not knee jerk respond by inheriting.

Answer 3

It's not a new idea, I believe it was actually introduced in the GoF design patterns book, which was published in 1994.

The main problem with inheritance is that it's white-box. By definition, you need to know the implementation details of the class you're inheriting from. With composition, on the other hand, you only care about the public interface of the class you're composing.

From the GoF book:

Inheritance exposes a subclass to details of its parent's implementation, it's often said that 'inheritance breaks encapsulation'

The wikipedia article on the GoF book has a decent introduction.

Answer 4

To answer part of your question, I believe this concept first appeared in the GOF Design Patterns: Elements of Reusable Object-Oriented Software book, which was first published in 1994. The phrase appears at the top of page 20, in the introduction:

Favor object composition over inheritance

They preface this statement with a brief comparison of inheritance with composition. They don't say "never use inheritance".

Answer 5

"Composition over inheritance" is a short (and apparently misleading) way of saying "When feeling that the data (or behaviour) of a class should be incorporated into another class, always consider using composition before blindly applying inheritance".

Why is this true ? Because inheritance creates tight, compile-time coupling between the 2 classes. Composition in contrast is loose coupling, wich among others enables clear separation of concerns, the possibility of switching dependencies at runtime and easier, more isolated dependency testability.

That only means inheritance should be handled with care because it comes at a cost, not that it isn't useful. Actually, "Composition over inheritance" often ends up being "Composition + inheritance over inheritance" since you often want your composed dependency to be an abstract superclass rather than the concrete subclass itself. It allows you to switch between different concrete implementations of your dependency at runtime.

For that reason (among others), you'll probably see inheritance used more often in the form of interface implementation or abstract classes than vanilla inheritance.

A (metaphorical) example could be :

"I have a Snake class and I want to include as part of that class what happens when the Snake bites. I would be tempted to have the Snake inherit a BiterAnimal class that has the Bite() method and override that method to reflect venomous bite. But Composition over Inheritance warns me that I should try to use composition instead... In my case, this could translate into the Snake having a Bite member. Bite class could be abstract (or an interface) with several subclasses. This would allow me nice things like having VenomousBite and DryBite subclasses and being able to change bite on the same Snake instance as the snake grows of age. Plus handling all the effects of a Bite in its own separate class could allow me to reuse it in that Frost class, because frost bites but isn't a BiterAnimal, and so on..."

Answer 6

Some possible arguments for composition:

Composition is slightly more language / framework agnostic
Inheritance and what it enforces / requires / enables will differ between languages in terms of what the sub/superclass have access to and what performance implications it may have wrt virtual methods etc. Composition is quite basic and requires very little language support, and thus implementations across different platforms / frameworks can share composition patterns more easily.

Composition is a very simple and tactile way of building objects
Inheritance is relatively easy to understand, but still not as easily demonstrated in real life. Many objects in real life can be broken down into parts and composed. Say a bicycle can be built using two wheels, a frame, a seat, a chain etc. Easily explained by composition. Whereas in an inheritance metaphor you could say that a bicycle extends a unicycle, somewhat feasible but still much further from the real picture than composition (obviously this is not a very good inheritance example, but the point remains the same). Even the word inheritance (at least of most US English speakers I would expect) automatically invokes a meaning along the lines "Something passed down from a deceased relative" which has some correlation with its meaning in software, but still only loosely fits.

Composition is almost always more flexible
Using composition you can always choose to define your own behavior or simply expose that part of your composed parts. This way you face none of the restrictions that may be imposed by an inheritance hierarchy (virtual vs. non-virtual etc.)

So, it could be because Composition is naturally a simpler metaphor that has less theoretical constraints than inheritance. Furthermore, these particular reasons may be more apparent during design time, or possibly stick out when dealing with some of the pain points of inheritance.

Disclaimer:
Obviously its not this clear cut / one way street. Each design merits evaluation of several patterns / tools. Inheritance is widely used, has lots of benefits and many times is more elegant than composition. These are just some possible reasons one could use when favoring composition.

Answer 7

Perhaps you just noticed people saying this in the last few months, but it has been known to good programmers for a lot longer than that. I've certainly been saying it where appropriate for about a decade.

The point of the concept is that there is a large conceptual overhead to inheritance. When you are using inheritance, then every single method call has an implicit dispatch in it. If you have deep inheritance trees, or multiple dispatch, or (even worse) both, then figuring out where the particular method will dispatch to in any particular call can become a royal PITA. It makes correct reasoning about the code more complex, and it makes debugging harder.

Let me give a simple example to illustrate. Suppose that deep in an inheritance tree, someone named a method foo. Then someone else comes along and adds foo at the top of the tree, but doing something different. (This case is more common with multiple inheritance.) Now that person working at the root class has broken the obscure child class and probably doesn't realize it. You could have 100% coverage with unit tests and not notice this breakage because the person at the top wouldn't think of testing the child class, and the tests for the child class don't think of testing the new methods created at the top. (Admittedly there are ways to write unit tests that will catch this, but there are also cases where you can't easily write tests that way.)

By contrast when you use composition, at each call it is usually clearer what you are dispatching the call to. (OK, if you're using inversion of control, for instance with dependency injection, then figuring out where the call goes can also get problematic. But usually it is simpler to figure out.) This makes reasoning about it easier. As a bonus, composition results in having methods segregated from each other. The above example should not happen there because the child class would move off to some obscure component, and there is never a question about whether the call to foo was intended for the obscure component or the main object.

Now you are absolutely right that inheritance and composition are two very different tools that serve two different types of things. Sure inheritance carries conceptual overhead, but when it is the right tool for the job, it carries less conceptual overhead than trying to not use it and do by hand what it does for you. Nobody who knows what they are doing would say that you should never use inheritance. But be sure it is the right thing to do.

Unfortunately many developers learn about object oriented software, learn about inheritance, and then go out to use their new axe as often as possible. Which means that they try to use inheritance where composition was the right tool. Hopefully they will learn better in time, but frequently this does not happen until after a few removed limbs, etc. Telling them up front that it is a bad idea tends to speed up the learning process and reduce injuries.

Answer 8

In one of the comment, Mason mentionned that one day we would be speaking about Inheritance considered harmful.

I hope so.

The problem with inheritance is at once simple, and deadly, it does not respect the idea that one concept should have one functionality.

In most OO-languages, when inheriting from a base class you:

• inherit from its interface
• inherit from its implementation (both data and methods)

And here become the trouble.

This is not the only approach, though 00-languages are mostly stuck with it. Fortunately interfaces / abstract classes exist in those.

Also, the lack of ease for doing otherwise contribute to making it largely used: frankly, even knowing this, would you inherit from an interface and embed the base class by composition, delegating most of the method calls ? It would be considerably better though, you'd even be warned if suddenly a new method pops in the interface and would have to choose, consciously, how to implement it.

As a counter-point, Haskell only allow to use the Liskov Principle when "deriving" from pure interfaces (called concepts) (1). You cannot derive from an existing class, only composition allow you to embed its data.

(1) concepts may provide a sensible default for an implementation, but since they have no data, this default can only be defined in term of the other methods proposed by the concept or in term of constants.

Answer 9

It's a reaction to the observation that OO beginners tend to use inheritance when they don't need to. Inheritance is certainly not a bad thing, but it can be overused. If one class just needs functionality from another, then composition will probably work. In other circumstances, inheritance will work and composition won't.

Inheriting from a class implies a lot of things. It implies that a Derived is a type of Base (see the Liskov Substitution principle for the gory details), in that whenever you use a Base it would make sense to use a Derived. It gives the Derived access to the protected members and member functions of Base. It's a close relationship, meaning it has high coupling, and changes to one are more likely to require changes to the other.

Coupling is a bad thing. It makes programs harder to understand and modify. Other things being equal, you should always select the option with less coupling.

Therefore, if either composition or inheritance will do the job effectively, choose composition, because it's lower coupling. If composition will not do the job effectively, and inheritance will, choose inheritance, because you have to.

Answer 10

Here are my two cents (beyond all the excellent points already raised):

IMHO, It comes down to the fact that most programmers don't really get inheritance, and end up overdoing it, partially as a result of how this concept is taught. This concept exists as a way to try to dissuade them from overdoing it, instead of focusing on teaching them how to do it right.

Anyone who has spent time teaching or mentoring knows that this is what often happens, especially with new developers who have experience in other paradigms:

These developers initially feel that inheritance is this scary concept. So they end up creating types with interface overlaps (e.g., same specified behavior without common subtyping), and with globals for implementing common pieces of functionality.

Then (often as a result of overzealous teaching), they learn about the benefits of inheritance, but it's often taught as the catch-all solution to reuse. They end up with a perception that any shared behavior must be shared through inheritance. This is because the focus is often on implementation inheritance rather than subtyping.

In 80% of the cases that's good enough. But the other 20% are where the problem starts. For the sake of avoiding rewriting and for making sure they have taken advantage of sharing implementation, they start designing their hierarchy around the intended implementation rather than the underlying abstractions. The "Stack inherits from doubly-linked list" is a good example of this.

Most teachers do not insist on introducing the concept of interfaces at this point, because it's either another concept, or because (in C++) you have to fake them using abstract classes and multiple inheritance which is not taught at this stage. In Java, many teachers do not distinguish the "no multiple inheritance" or "multiple inheritance is evil" from the importance of interfaces.

All this is compounded by the fact that we've learned so much of the beauty of not having to write superfluous code with implementation inheritance, that tons of straightforward delegation code looks unnatural. So composition looks messy, which is why we need these rules of thumbs to push new programmers to use them anyway (which they overdo as well).

Answer 11

The simple answer is: inheritance has greater coupling than composition. Given two options, of otherwise equivalent qualities, choose the one that is less coupled.

Answer 12

I think this sort of advice is like saying "prefer driving to flying". That is, planes have all sorts of advantages over cars, but that comes with a certain complexity. So if many people try to fly from the city centre to the suburbs, the advice they really, really need to hear is that they don't need to fly, and in fact, flying will just make it more complicated in the long run, even if it seems cool/efficient/easy in the short term. Whereas when you do need to fly, it's generally supposed to be obvious.

Likewise, inheritence can do things composition can't, but you should use that when you need it, and not when you don't. So if you're never tempted to just assume you need inheritence when you don't, then you don't need the advice of "prefer composition". But many people do, and do need that advice.

It's supposed to be implicit that when you really DO need inheritance, it's obvious, and you should use it then.

Also, Steven Lowe's answer. Really, really that.

Answer 13

Inheritance isn't inherently bad, and composition isn't inherently good. They are merely tools that an OO programmer can use to design software.

When you look at a class, is it doing more than it absolutely should (SRP)? Is it duplicating functionality unnecessarily (DRY), or is it overly interested in the properties or methods of other classes (Feature Envy)?. If the class is violating all of these concepts (and possibly more), is it attempting to be a God Class. These are a number of problems that can occur when designing software, none of which is necessarily an inheritance problem, but which can quickly create major headaches and brittle dependencies where polymorphism has also been applied.

The root of the problem likely to be less a lack of understanding about inheritance, and more one of either poor choice in terms of design, or perhaps not recognizing "code smells" relating to classes that are not adhering to the Single Responsibility Principle. Polymorphism and Liskov Substitution need not be discarded in favour of composition. Polymorphism itself can be applied without relying on inheritance, these are all quite complimentary concepts. If applied thoughtfully. The trick is to aim to keep your code simple, and clean, and to not to succumb to being overly concerned about the number of classes that you need to create in order to create a robust system design.

In so far as the issue of favouring composition over inheritance, this is really just another case of the thoughtful application of the design elements that make the most sense in terms of the problem being solved. If you don't need to inherit behaviour, then you probably shouldn't as composition will help to avoid incompatibilities and major refactoring efforts later on. If on the other hand you find that you are repeating a lot of code such that all of the duplication is centred on a group of similar classes, then it may be that creating a common ancestor would help to reduce the number of identical calls and classes you might need to repeat between each class. Thus, you are favouring composition, yet you aren't assuming that inheritance is never applicable.

Answer 14

The actual quote comes, I believe, from Joshua Bloch's "Effective Java", where it is the title of one of the chapters. He claims that inheritance is safe within a package and wherever a class has been specifically designed and documented for extension. He claims, as others have noted, that inheritance breaks encapsulation because a subclass depends on the implementation details of its superclass. This leads, he says, to fragility.

Although he doesn't mention it, it seems to me that single inheritance in Java means that composition gives you much more flexibility than inheritance.