Composition Over Inheritance, With Examples

01Where inheritance breaks

• Fixed at compile time. A subclass cannot change what it inherits while running; a composed dependency can be swapped.
• The fragile base class. Changing a parent method silently alters every subclass, including ones written by other teams.
• Combinatorial explosion. Three orthogonal traits force eight subclasses to cover the combinations.
• One parent only. In Java and C#, a class inherits from exactly one class, so the first inheritance decision spends the budget.

class Bird { void fly() {} void swim() {} }

class Penguin extends Bird {
    void fly() { throw new UnsupportedOperationException(); }   // a lie
}

Penguin is a bird but cannot fly, so it inherits a method it must refuse — and every caller holding a Bird can now crash. That is a Liskov violation, and the compiler will not catch it.

02The composition version

interface Flies    { void fly(); }
interface Swims    { void swim(); }

class Sparrow implements Flies          { public void fly()  { /* ... */ } }
class Penguin implements Swims          { public void swim() { /* ... */ } }
class Duck    implements Flies, Swims   { public void fly()  { }  public void swim() { } }

No class carries a method it cannot honour, capabilities combine freely, and a new one is a new interface rather than a rewrite of the hierarchy.

03How this connects to SOLID

• S — Single responsibility. One reason to change per class; large inheritance trees usually violate it first.
• O — Open/closed. Open for extension, closed for modification — which is exactly what polymorphic dispatch buys.
• L — Liskov substitution. A subclass must work anywhere its parent does. The penguin fails this.
• I — Interface segregation. Many small contracts beat one large one; Flies and Swims instead of Bird.
• D — Dependency inversion. Depend on abstractions, not concrete classes — which is composition through an interface.