Composition Over Inheritance

Overview

Favor object composition over class inheritance.

Inheritance creates tight coupling and rigid hierarchies. Composition creates flexible, reusable components that can be mixed and matched.

When to Use

• Designing relationships between classes
• Tempted to use extends
• Class needs behavior from multiple sources
• Creating "is-a" relationships
• Building class hierarchies

The Iron Rule

NEVER use inheritance when composition would work.

No exceptions:

• Not for "it's the OOP way"
• Not for "is-a relationship"
• Not for "code reuse via extends"
• Not for "polymorphism"

Default to composition. Use inheritance only for true type hierarchies.

Detection: The Inheritance Smell

If inheritance feels awkward or forced, use composition:

// ❌ VIOLATION: Inheritance hierarchy
class Animal {
  eat(): void { console.log('Eating'); }
}

class FlyingAnimal extends Animal {
  fly(): void { console.log('Flying'); }
}

class SwimmingAnimal extends Animal {
  swim(): void { console.log('Swimming'); }
}

// Duck needs both fly AND swim - inheritance can't do this cleanly
class Duck extends FlyingAnimal {
  swim(): void { console.log('Swimming'); } // Duplicated!
}

Correct Pattern: Composition with Interfaces

Define capabilities as interfaces, compose them:

// ✅ CORRECT: Composition
interface Flyable {
  fly(): void;
}

interface Swimmable {
  swim(): void;
}

interface Eatable {
  eat(): void;
}

// Reusable behaviors
const flyingBehavior: Flyable = {
  fly() { console.log('Flying'); }
};

const swimmingBehavior: Swimmable = {
  swim() { console.log('Swimming'); }
};

const eatingBehavior: Eatable = {
  eat() { console.log('Eating'); }
};

// Compose what you need
class Duck implements Flyable, Swimmable, Eatable {
  fly = flyingBehavior.fly;
  swim = swimmingBehavior.swim;
  eat = eatingBehavior.eat;
}

class Fish implements Swimmable, Eatable {
  swim = swimmingBehavior.swim;
  eat = eatingBehavior.eat;
}

class Bird implements Flyable, Eatable {
  fly = flyingBehavior.fly;
  eat = eatingBehavior.eat;
}

Why Inheritance Fails

Why Composition Wins

Pressure Resistance Protocol

1. "It's the OOP Way"

Pressure: "Object-oriented programming uses inheritance"

Response: Modern OOP favors composition. Inheritance is overused.

Action: Use interfaces + composition. It's still OOP.

2. "It's an Is-A Relationship"

Pressure: "A Duck IS-A Bird, so it should extend Bird"

Response: "Is-a" often becomes "has-a" when requirements change. Composition handles both.

Action: Model as "has behaviors" not "is a type".

3. "Code Reuse via Extends"

Pressure: "I need the parent's methods"

Response: Composition provides better code reuse without coupling.

Action: Extract shared behavior into composable units.

4. "Polymorphism Requires Inheritance"

Pressure: "I need to treat different types uniformly"

Response: Interfaces provide polymorphism without inheritance.

Action: Define interface, have classes implement it.

Red Flags - STOP and Reconsider

If you notice ANY of these, use composition instead:

• extends keyword in your code
• Class hierarchy deeper than 2 levels
• Child class overriding parent methods
• "Diamond problem" - needs multiple parents
• Subclass doesn't use all parent methods
• Changing parent breaks children
• Hard to test without instantiating parent

All of these mean: Refactor to composition.

When Inheritance IS Appropriate

Use inheritance only when:

• True type hierarchy (rarely)
• Framework requires it (React class components, etc.)
• Extending library classes you don't control

Even then, keep hierarchy shallow (max 2 levels).

Quick Reference

Common Rationalizations (All Invalid)

The Bottom Line

Compose behaviors. Don't inherit them.

When designing classes: define interfaces for capabilities, create composable behaviors, inject what each class needs. Use extends only as last resort.