Dependency Inversion Principle (DIP)

The two formal rules

Robert C. Martin states DIP as two rules. They sound abstract; we'll make them concrete in a moment.

• Rule 1 — High-level modules should not depend on low-level modules. Both should depend on abstractions. (Your OrderService shouldn't depend on MySQLDatabase; both should depend on an OrderRepository interface.)
• Rule 2 — Abstractions should not depend on details. Details should depend on abstractions. (The interface shouldn't mention MySQL-specific types; instead, MySQLOrderRepository is the one that bends to fit the interface.)

The classic smell: a service that `new`s its own tool

Here is the trap, and almost everyone writes it at first. A high-level class builds the concrete tool it needs inside itself:

class OrderService {            // high-level policy
  private email = new EmailSender();   // ⚠️ welded to a concrete detail

  placeOrder(order: Order) {
    // ...business rules...
    this.email.send(order.customer, "Your order is confirmed");
  }
}

That single new EmailSender() line quietly causes two real problems. You can't swap it — the day product wants SMS instead of email, you have to open OrderService and edit business-critical code just to change a delivery channel. And you can't test it — every test of OrderService now fires a real email, because the service insists on building the real sender. The policy has been welded to a detail it should never have cared about.

The fix: depend on an interface, inject the detail

Introduce an interface that describes what the policy needs — MessageSender with a send(...) method — and have OrderService hold one of those instead of a concrete sender. Then pass the real implementation in from outside, through the constructor:

interface MessageSender {                // the abstraction (the "socket")
  send(to: string, text: string): void;
}

class OrderService {
  constructor(private sender: MessageSender) {}  // injected from outside

  placeOrder(order: Order) {
    // ...business rules...
    this.sender.send(order.customer, "Your order is confirmed");
  }
}

class EmailSender implements MessageSender { /* ... */ }   // a detail
class SMSSender   implements MessageSender { /* ... */ }   // another detail

new OrderService(new EmailSender());   // wire it up at the edge of the app

Where the "inversion" actually is

The name confuses people, so look closely at the arrows. Before, the dependency arrow ran downward: policy → detail (OrderService → MySQLDatabase). The high-level code pointed at, and was at the mercy of, the low-level code. After, that arrow is inverted: the detail now points up at the abstraction (MySQLOrderRepository → OrderRepository), and the policy points at the same abstraction. The crucial twist is that the interface is owned by the high-level side — it's defined in terms of what the policy needs, and the detail must conform to it. The detail now serves the policy, not the other way around. That reversal of who-conforms-to-whom is the 'inversion'.

Why this is the whole point

• Swapping — to go from email to SMS you write a new SMSSender implements MessageSender and change one wiring line at the edge of the app. OrderService is never opened.
• Testing — in a unit test you inject a FakeSender that just records what it was asked to send. The test is fast, offline, and asserts on the recording — no real email, no real database.
• Decoupling — the policy and the detail no longer know each other's names. Either can change independently as long as the interface holds. That's loose coupling, and it's what keeps a large codebase soft enough to change.

Invert the dependencies that are likely to change

DIP earns its keep around volatile or external dependencies — anything that talks to the outside world or that you might reasonably want to replace, fake, or reconfigure. These are exactly the things that make code hard to test and hard to evolve when you new them inline.

• Databases / persistence — OrderRepository interface in front of MySQL, Postgres, or an in-memory store for tests.
• Network & third-party services — payment gateways, email/SMS providers, an HTTP client to another team's API.
• The clock and randomness — wrap now() and random() behind an interface so tests can pin time and seeds instead of being flaky.
• Anything you want to fake in a unit test — if you can't test a class without standing up real infrastructure, that dependency wants inverting.