foundation · 12 MIN READ

Composition over Inheritance

Composition assembles a behavior from collaborators that can vary independently. Favor it when an inheritance hierarchy would multiply subclasses for every combination of policies.

Reading completion is independent of quizzes and challenges.

What you’ll understand

Composition assembles a behavior from collaborators that can vary independently. Favor it when an inheritance hierarchy would multiply subclasses for every combination of policies.
Inject a shipping collaborator rather than introducing StandardCheckout and ExpressCheckout subclasses.
Evaluate the tradeoff: Composition introduces delegation and object wiring. Inheritance remains useful for genuine stable substitutable subtypes; the principle is a preference, not a universal ban.

Useful first: Classes and Objects

The idea and when to recognize it

Composition assembles a behavior from collaborators that can vary independently. Favor it when an inheritance hierarchy would multiply subclasses for every combination of policies.

Requirement: A checkout needs either standard or express shipping without becoming a different checkout subtype.
Change to anticipate: Change delivery policy while preserving the same checkout object contract.
Design goal: Inject a shipping collaborator rather than introducing StandardCheckout and ExpressCheckout subclasses.

Start with the concrete problem

A checkout needs either standard or express shipping without becoming a different checkout subtype.

Change delivery policy while preserving the same checkout object contract.

Direct implementation	Revised design
Creating a subclass for every delivery option couples checkout identity to a changeable policy.	Inject a shipping collaborator rather than introducing StandardCheckout and ExpressCheckout subclasses.
The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design.	Composition introduces delegation and object wiring. Inheritance remains useful for genuine stable substitutable subtypes; the principle is a preference, not a universal ban.

Responsibilities and contracts

Inject a shipping collaborator rather than introducing StandardCheckout and ExpressCheckout subclasses.

Checkout: Combines prices through a stable operation. Public operations: total(items)
ShippingPolicy: Hides fee selection. Public operations: fee()

Read the design

Select a participant to inspect its responsibility and public operations. Follow the labeled relationships; an arrow indicates direction, while the legend distinguishes ownership, substitution, and temporary use.

class diagramSelect a participant below

Checkout

Combines prices through a stable operation

total(items)

Relationships and notation

Checkout → ShippingPolicy: delegates to. Association · knows another object

Preparing the design walkthrough…

Follow the interaction

Choose a supplied workload and compare the direct and revised implementations. Step through the same operation in both languages. Object values are recorded after each highlighted statement; previous steps remain unchanged.

GUIDED SIMULATIONExample language

Scenario Implementation

Standard shipping adds four units.

A finite, authored walkthrough of this fixture. Source code is verified in tests; it is not executed by this page.

class diagramSelect a participant below

Checkout

Combines prices through a stable operation

total(items)

Relationships and notation

Checkout → ShippingPolicy: delegates to. Association · knows another object

Object state after the highlighted operation

{}

function example(input) {
  class ShippingPolicy { constructor(express) { this.express = express; } fee() { return this.express ? 12 : 4; } }
  class Checkout { constructor(policy) { this.policy = policy; } total(items) { return items.reduce((a,b)=>a+b,0) + this.policy.fee(); } }
  const checkout = new Checkout(new ShippingPolicy(input.express));
  const total = checkout.total(input.items);
  return total;
}

Ready to explore

Press Next to construct the collaborators, then follow the operation and inspect its result.

Step 0 / 3

Textual interaction history

Preparing the design walkthrough…

Implementation and expected output

Read the complete example alongside its input and expected output. The implementation selector changes the displayed program; the language selector preserves your current scenario and playback position.

Example language

Revised design · Call example(input) with the selected fixture.

Complete JavaScript implementation

function example(input) {
  class ShippingPolicy { constructor(express) { this.express = express; } fee() { return this.express ? 12 : 4; } }
  class Checkout { constructor(policy) { this.policy = policy; } total(items) { return items.reduce((a,b)=>a+b,0) + this.policy.fee(); } }
  const checkout = new Checkout(new ShippingPolicy(input.express));
  const total = checkout.total(input.items);
  return total;
}

Input

{
  "express": false,
  "items": [
    10,
    20
  ]
}

Expected contract result

Preparing the design walkthrough…

Try the idea in another setting

A game character can compose movement and attack behaviors instead of creating a subclass for every pair.

Name the new client contract before adapting the example.
Identify which state belongs to each object and who controls its lifetime.
Write one normal case and one boundary case before extending the design.

Tradeoffs and interview takeaways

Composition introduces delegation and object wiring. Inheritance remains useful for genuine stable substitutable subtypes; the principle is a preference, not a universal ban.

Common mistake: Creating a subclass for every delivery option couples checkout identity to a changeable policy.

Explain the choice: Inject a shipping collaborator rather than introducing StandardCheckout and ExpressCheckout subclasses.
Challenge your choice: Composition introduces delegation and object wiring. Inheritance remains useful for genuine stable substitutable subtypes; the principle is a preference, not a universal ban.
Describe a requirement that would make the simpler implementation sufficient.

Design challenge and knowledge check

Preparing the design walkthrough…

Navigation

Course navigation

Composition over Inheritance

What you’ll understand

The idea and when to recognize it

Start with the concrete problem

Responsibilities and contracts

Read the design

Follow the interaction

Implementation and expected output

Try the idea in another setting

Tradeoffs and interview takeaways

Design challenge and knowledge check

Meet the contract across every scenario

Five decisions to remember

Make it your own

Meet the contract across every scenario

Five decisions to remember