Composition over Inheritance

In simple words#

Learning objectives#

• Explain the class-explosion problem with inheritance
• Build behaviour by combining objects
• Swap behaviour at runtime
• Know when inheritance is still the right tool

Explanation#

Inheritance fixes behaviour at compile time and supports only one parent. Combine two features — petrol or electric, with or without GPS — and you need PetrolCar, ElectricCar, PetrolCarWithGps, ElectricCarWithGps. Each new feature doubles the classes.

Composition gives the car a powerSource object and an optional gps object. Any power source and any GPS can be combined — two small classes per feature, not a multiplying tree.

Composed parts can be replaced at runtime (fit a GPS later) and tested on their own.

Changes to a base class ripple into every subclass (the “fragile base class” problem). Composed parts only interact through small interfaces, so changes stay local.

Inheritance is still right for true, stable is-a relationships with shared behaviour — a SavingsAccount is an Account. Use composition for “has a” and “can do”.

Syntax#

1public interface IPowerSource { string Start(); }
2public interface INavigator { string Route(string to); }
3

4public class Car(string name, IPowerSource power, INavigator? gps = null)
5{
6    public string Start() => 
quot;{name}: {power.Start()}";
7    public string Navigate(string to) => gps?.Route(to) ?? "no GPS fitted";
8}

Code example: Cars built from parts#

1// Inheritance would need: PetrolCar, ElectricCar, PetrolCarWithGps, ElectricCarWithGps...
2// Composition: small parts, combined freely.
3

4class PetrolEngine {
5  constructor(hp) { this.hp = hp; }
6  start() { return `engine ${this.hp}hp started`; }
7}
8

9class ElectricMotor {
10  constructor(kw) { this.kw = kw; }
11  start() { return `motor ${this.kw}kW humming`; }
12}
13

14class Gps {
15  route(to) { return `route to ${to}`; }
16}
17

18class Car {
19  constructor(name, powerSource, gps = null) {
20    this.name = name;
21    this.power = powerSource;   // has-a power source
22    this.gps = gps;             // has-a (optional) GPS
23  }
24  start() { return `${this.name}: ${this.power.start()}`; }
25  navigate(to) { return this.gps ? this.gps.route(to) : 'no GPS fitted'; }
26}
27

28const city = new Car('City', new PetrolEngine(120), new Gps());
29const nexon = new Car('Nexon EV', new ElectricMotor(105));
30

31console.log(city.start());
32console.log(nexon.start());
33console.log(city.navigate('Pune'));
34console.log(nexon.navigate('Pune'));
35

36nexon.gps = new Gps();          // fitted later, at runtime
37console.log(nexon.navigate('Mumbai'));

City: engine 120hp started
Nexon EV: motor 105kW humming
route to Pune
no GPS fitted
route to Mumbai

Step-by-step explanation#

1. PetrolEngine and ElectricMotor both have start(), so the car can use either.
2. Car does not inherit from an engine; it holds one and delegates to it.
3. The optional GPS is another part. No GPS → a sensible message instead of a new class.
4. Fitting a GPS later is just assigning a new part — impossible with inheritance, where the class is fixed.

Real-world use case#

Common mistakes#

Best practices#

• Ask “is-a or has-a?” before writing extends
• Put varying behaviour into small, swappable parts
• Depend on interfaces for those parts
• Keep inheritance hierarchies shallow (1–2 levels)

Remember this#

Practice exercise#

1class Sword { attack() { return 'slashes for 10'; } }
2class Bow { attack() { return 'shoots for 7'; } }
3class Character {
4  constructor(name, weapon) { this.name = name; this.weapon = weapon; }
5  attack() { return `${this.name} ${this.weapon.attack()}`; }
6}
7const hero = new Character('Arjun', new Sword());
8console.log(hero.attack()); // Arjun slashes for 10
9hero.weapon = new Bow();
10console.log(hero.attack()); // Arjun shoots for 7

Mini quiz#

Want more? Practise all OOP Concepts MCQs · OOP Concepts interview questions

Related topics#

My notes#

Saved in this browser.