Composition vs Inheritance

The "is-a" vs "has-a" test

Before reaching for either tool, say the relationship out loud. If "a B is a A" sounds true — "a Dog is an Animal" — inheritance fits. If it sounds wrong but "a B has a A" is true — "a Character has a fly behavior" — that's composition. A character is not a kind of flying; it merely has a way to move. Getting this test right is the whole ballgame.

Why inheritance explodes

Inheritance forces every variation into the class tree. Suppose a character can move three ways (walk / fly / swim), attack two ways (sword / laser), and either have a shield or not. To cover every combination with subclasses you'd need one class per combination:

// one subclass for every combination of abilities…
3 (move) × 2 (attack) × 2 (defense) = 12 subclasses
// add a fourth move option and it jumps to 4 × 2 × 2 = 16
// add another axis (say 3 armor tiers) → 12 × 3 = 36

This is the combinatorial explosion. Each new option multiplies the number of classes, and any shared logic gets copy-pasted across cousins in the tree. Worse, a tweak to a base class can quietly break dozens of descendants — the fragile base class problem.

How composition assembles small behaviors

Composition flips it. Instead of one class per combination, you write a handful of tiny behavior objects — FlyBehavior, SwimBehavior, LaserAttack, SwordAttack — each doing one thing. The Character just holds references to them and delegates: when asked to move, it calls this.moveBehavior.move(). Three move behaviors, two attack behaviors, and an optional shield cover all twelve combinations with only seven small objects, no subclass tree at all.

class Character {
  constructor(
    private moveBehavior: MoveBehavior,    // HELD, not inherited
    private attackBehavior: AttackBehavior,
  ) {}

  performMove()   { return this.moveBehavior.move(); }     // delegate
  performAttack() { return this.attackBehavior.attack(); }

  // swap a behavior at RUNTIME — impossible with a fixed subclass
  setMove(b: MoveBehavior) { this.moveBehavior = b; }
}

Because the behavior lives in a field, you can change it while the program runs: hero.setMove(new FlyBehavior()) turns a walker into a flyer instantly. A subclass can never do that — its identity is fixed the moment it's constructed. (This swap-a-behavior-at-runtime idea is exactly the Strategy pattern, which you'll meet later — it's composition with a name.)

Favor composition over inheritance — and why

The famous guideline from the Gang of Four is "favor object composition over class inheritance." The reasons are concrete:

• Loose coupling — the Character depends on small behavior interfaces, not on a sprawling parent's internals. Parts evolve independently.
• No fragile base class — there's no deep tree where a base-class change ripples into every descendant.
• Runtime flexibility — behaviors are plugged in (and swapped) while the program runs, instead of being frozen at design time.
• No combinatorial explosion — new options add behaviors instead of multiplying classes.

When inheritance is fine

Use inheritance when there's a genuine is-a relationship with real shared behavior, and you want polymorphism over the base type — a SavingsAccount is a BankAccount, a Circle is a Shape. The hierarchy is shallow, stable, and honest. If the is-a sentence rings true and you'd happily treat every subclass through the parent's interface, inheritance is the cleaner tool.

When to prefer composition

Prefer composition the moment you're reaching for inheritance just to reuse code, or when a type's capabilities vary along several independent axes (how it moves, attacks, defends). If you find yourself wanting to mix and match — or change behavior while the program runs — hold the behaviors as fields and delegate. That's the has-a shape, and it keeps the design flat, loosely coupled, and easy to extend.