foundation · 12 MIN READ

Dependency Inversion

High-level policy should depend on a stable abstraction rather than directly construct a low-level detail. Both policy and detail agree on the boundary contract.

Reading completion is independent of quizzes and challenges.

What you’ll understand

High-level policy should depend on a stable abstraction rather than directly construct a low-level detail. Both policy and detail agree on the boundary contract.
Inject a sender that fulfills the message contract instead of constructing a provider inside policy code.
Evaluate the tradeoff: An abstraction boundary adds wiring and requires contract tests. Dependency injection is one implementation technique; the principle is the direction of dependency.

Useful first: Classes and Objects

The idea and when to recognize it

High-level policy should depend on a stable abstraction rather than directly construct a low-level detail. Both policy and detail agree on the boundary contract.

Requirement: Receipt delivery policy should work without depending on a concrete email provider.
Change to anticipate: Substitute SMS delivery without editing the receipt service.
Design goal: Inject a sender that fulfills the message contract instead of constructing a provider inside policy code.

Start with the concrete problem

Receipt delivery policy should work without depending on a concrete email provider.

Substitute SMS delivery without editing the receipt service.

Direct implementation	Revised design
Constructing the email SDK in the receipt method prevents substitution and isolated testing.	Inject a sender that fulfills the message contract instead of constructing a provider inside policy code.
The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design.	An abstraction boundary adds wiring and requires contract tests. Dependency injection is one implementation technique; the principle is the direction of dependency.

Responsibilities and contracts

Inject a sender that fulfills the message contract instead of constructing a provider inside policy code.

ReceiptService: Depends on the sender contract. Public operations: send(message)
Sender: Defines message delivery. Public operations: send(message)
EmailSender: Implements the same contract. Public operations: send(message)

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

ReceiptService

Depends on the sender contract

send(message)

Relationships and notation

ReceiptService → Sender: depends on. Dependency → uses temporarily
EmailSender → Sender: implements. Realization ⇢ fulfills a contract

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

The original sender delivers the receipt.

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

ReceiptService

Depends on the sender contract

send(message)

Relationships and notation

ReceiptService → Sender: depends on. Dependency → uses temporarily
EmailSender → Sender: implements. Realization ⇢ fulfills a contract

Object state after the highlighted operation

{}

function example(input) {
  class EmailSender { send(message) { return "email:" + message; } }
  class SmsSender { send(message) { return "sms:" + message; } }
  class ReceiptService { constructor(sender) { this.sender = sender; } notify(message) { return this.sender.send(message); } }
  const service = new ReceiptService(input.channel === "sms" ? new SmsSender() : new EmailSender());
  const result = service.notify(input.message);
  return result;
}

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 EmailSender { send(message) { return "email:" + message; } }
  class SmsSender { send(message) { return "sms:" + message; } }
  class ReceiptService { constructor(sender) { this.sender = sender; } notify(message) { return this.sender.send(message); } }
  const service = new ReceiptService(input.channel === "sms" ? new SmsSender() : new EmailSender());
  const result = service.notify(input.message);
  return result;
}

Input

{
  "channel": "email",
  "message": "receipt"
}

Expected contract result

"email:receipt"

Preparing the design walkthrough…

Try the idea in another setting

An order policy can depend on a repository contract realized by an in-memory test repository and a database implementation.

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

An abstraction boundary adds wiring and requires contract tests. Dependency injection is one implementation technique; the principle is the direction of dependency.

Common mistake: Constructing the email SDK in the receipt method prevents substitution and isolated testing.

Explain the choice: Inject a sender that fulfills the message contract instead of constructing a provider inside policy code.
Challenge your choice: An abstraction boundary adds wiring and requires contract tests. Dependency injection is one implementation technique; the principle is the direction of dependency.
Describe a requirement that would make the simpler implementation sufficient.

Design challenge and knowledge check

Preparing the design walkthrough…

Navigation

Course navigation

Dependency Inversion

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