Dependency inversion D

01 / MEET THE PRINCIPLE

What is Dependency inversion?

Keep high-level policy dependent on an abstraction it needs, rather than on the details of a particular implementation.

First understand the idea. Then explore why it helps, before bringing it to life in the harbour.

WHERE THE IDEA BEGAN

A little history.

Robert C. Martin described dependency inversion among the principles in his 2000 paper. It reverses the usual source-code dependency from business policy toward implementation details by introducing an abstraction.

02 / WHY IT MATTERS

Why use it?

Where it helps

Useful where business rules meet databases, email services, payment gateways or hardware. A boundary can also allow a controlled test double.

Why use it?

The policy can remain stable while the implementation changes. Both the policy and the adapter refer to the contract, while a composition step chooses what is connected.

What if you ignore it?

Changes in infrastructure spread into business rules. Tests become slow or awkward because they must construct real external services.

KNOW THE TRADE-OFF

Useful, not absolute.

Dependency injection is one wiring technique; it is not the principle itself. A DI container is optional. Avoid wrapping every stable value or simple utility in an interface without a useful boundary.

Next, step into the story and see this problem through a familiar situation.

03 / ONCE UPON A CHANGE

Keep the light.
Change the power.

The lighthouse’s signalling routine creates and operates one particular diesel generator. Switching to a battery means editing the signalling code. Worse, testing the signal drags a real generator into the test. The purpose of the light has become tangled with its power supply.

The light defines the power capability it needs. Generators and batteries provide that capability. A separate setup step plugs the chosen source into the light.

Turn to “Try it” to change the design and see what happens.

04 / PULL THE PAPER TAB

What happens
when things change?

Signal code constructs a concrete DieselGenerator.

Signal code constructs a concrete DieselGenerator.

Choose a scenario, then try the change.

An illustrative model, not a benchmark or a claim that every design change causes a bug.

05 / FROM STORY TO CODE

Spot the dependency.

Keep high-level policy dependent on an abstraction it needs, rather than on the details of a particular implementation.

Before

class Lighthouse
{
    private readonly DieselGenerator power =
        new DieselGenerator();
    public void Signal() { power.Supply(); }
}

A MORE FOCUSED DESIGN

After

interface IPower { void Supply(); }
class Lighthouse
{
    private readonly IPower power;
    public Lighthouse(IPower power) { this.power = power; }
    public void Signal() { power.Supply(); }
}
// Setup: new Lighthouse(new Battery());

Illustrative C# sketches. Supporting types and method bodies are omitted; these snippets are not executed in the page.

06 / MAKE IT STICK

Take the idea
with you.

Keep high-level policy dependent on an abstraction it needs, rather than on the details of a particular implementation.

Try the question opposite, then continue to the next principle.