Composition builds behavior by holding other objects (a "has-a" relationship) and delegating to them. Inheritance acquires behavior by extending a class ("is-a"). The advice "favor composition" exists because inheritance creates tight, fragile coupling to a base class, while composition stays flexible.
<T> <T> {
{ add(x); }
T { remove(size() - ); }
}
class Stack<T> {
private final List<T> items = new ArrayList<>(); // HAS-A list
void push(T x) { items.add(x); }
T pop() { return items.remove(items.size() - 1); }
// only push/pop are exposed → LIFO invariant is safe
}
By holding a list instead of being one, Stack exposes only the operations it wants.
| Composition | Inheritance |
|---|---|
| Flexible, swap parts at runtime | Fixed at compile time |
| Hides internals (delegation) | Inherits whole interface |
| More wiring/boilerplate | Less code when truly is-a |
| Avoids fragile base class | Subclass breaks if base changes |
Use inheritance only for genuine, stable is-a relationships; use composition for "I need this behavior."
Inheritance exposes the parent's entire interface, so a subclass can't fully control its own contract — the Stack extends ArrayList leak is the classic example.
Composition keeps relationships explicit and swappable, which is why dependency injection, strategy patterns, and most flexible designs lean on it.