Composition over inheritance

Why did the feature invented to let programs reuse code become the one to avoid?

Inheritance was, for a generation, the headline feature of object-oriented programming: write a class, then write another that gets everything the first had and adds a little. Reuse without copying, taught in every first course.

Then the advice inverted. The Gang of Four wrote "favor object composition over class inheritance" in 1994 — inside the book that popularised object-oriented design. Modern languages ship without implementation inheritance at all and nobody misses it much. So what went wrong with a mechanism that does exactly what it advertises?

Begin with what inheritance actually gives you, because it gives two things at once and they are usually conflated.

The first is subtyping: a promise that instances of the child can be used wherever the parent was expected. The second is implementation reuse: the child gets the parent's code and fields for free. Those are separate ideas, and inheritance welds them together. Most of the trouble follows from that welding.

Take reuse first. What exactly does a subclass inherit? Not just a set of methods — it inherits the parent's internal arrangement, because its methods run inside the parent's object, touch its fields, and call its other methods. So a subclass depends on which internal method the parent happens to call from which other one. Consider a collection whose addAll is implemented by looping over add, and a subclass that counts insertions by overriding both. The count is doubled — not because either class is wrong, but because the subclass depended on an implementation detail the parent never promised. Rewrite addAll to copy the buffer directly, and the count silently changes again. This is the fragile base class problem: the parent cannot safely change its own private choices, because a subclass may have taken them as an interface.

Notice how much stronger that is than ordinary dependency. A caller of a function depends on its signature and behaviour. A subclass depends on its internals. Inheritance is therefore about the tightest coupling a language offers — and it is offered as the beginner's tool for reuse.

Now take subtyping, and ask what the promise actually costs. If a child can stand in for a parent everywhere, then it must honour everything a caller could rely on about the parent — this is Liskov's substitution principle. The uncomfortable consequence is that inheriting is a commitment to every method, including the ones that make no sense for you. The stock example is a read-only document class inheriting save. It can throw, but then a caller holding a perfectly ordinary reference gets a failure the type system said could not happen. The hierarchy typechecks and lies.

Then there is the shape problem. A class hierarchy is a tree, so every class has exactly one parent, and you must choose which single axis of variation the tree encodes. Real requirements have several axes — storage medium, formatting, permissions, locale — and a tree can only express one of them cleanly. Model two and the leaves multiply combinatorially, which is why old hierarchies acquire classes with names like BufferedEncryptedRemoteFileReader.

So what does composition change? It splits the two ideas apart. An object holds another object and delegates to it, so it reuses behaviour without inheriting internals; and it separately declares which interfaces it implements, so subtyping is asserted only where it is true. The axes stop competing, because each collaborator varies independently — a reader with any storage, any encoding, chosen at construction rather than at compile time by picking a leaf of a tree.

One honest qualification. This is a default, not a prohibition. Inheritance remains a good fit where the hierarchy is genuinely a fixed classification that the author controls end to end — abstract syntax tree nodes, algebraic data types, sealed hierarchies of exceptions — because there the base class and all its children change together by design, and the fragility argument mostly evaporates. What went wrong was inheritance used across module boundaries, and used for reuse rather than for classification.

Three clarifications.

First, "composition over inheritance" is not "interfaces are bad". Interface inheritance — declaring that you implement a set of operations — carries none of the fragility, because there is no implementation to depend on. The advice targets implementation inheritance specifically. Languages that kept the first and dropped the second, and use embedding or traits for reuse, are following exactly this reading.

Second, composition is not free. Delegation means writing forwarding methods, more objects to wire up, and indirection at the point where you would like to read the behaviour in one place. Some languages take that sting away with delegation syntax or mixins; in others it is real boilerplate, and pretending otherwise is why the advice sometimes feels doctrinaire.

Third, the useful test at the moment of choice is not "is this an X" but "would I accept being broken by this parent's private changes, forever?" If the parent lives in another library, another team, or another release cadence, the answer is almost always no — and then composition is not a stylistic preference but the only arrangement that survives the next upgrade.

• How mixins, traits, and embedding try to recover inheritance's convenience without its fragility.
• Liskov substitution as a rule about behaviour rather than signatures, and what it forbids in practice.

Every term the collection defines is gathered in the glossary.