Inversion of control: how dependencies reach a class

A team wants to test their OrderService. The test creates one — and a real Postgres connection opens, a real Stripe call fires, and a real email is sent to a real address. They cannot test the logic without the entire production stack, because the constructor does this.db = new PgClient(), this.payments = new StripeClient(), this.mail = new Mailer(). The logic was never the problem. The wiring was.

The coupling created by new

When a class writes new EmailService() inside itself, it has made an irreversible decision for every caller: this code is the real email service, always. You cannot substitute a fake in a test, swap a different implementation per environment, or reuse the class with a different collaborator. The dependency is hidden (invisible in the type) and hard (welded at construction).

Inversion of control

Inversion of control (IoC) flips who decides. Instead of the class choosing its concrete collaborator, the class declares an abstract need and something else supplies the concrete one. Dependency injection is the most common form of IoC: dependencies are injected from outside rather than constructed inside.

The cleanest injection is constructor injection:

class OrderService {
  constructor(
    private db: Database,
    private payments: PaymentGateway,
    private mail: Mailer,
  ) {}
}

Now the constructor signature is an honest, compile-time-checked list of everything the class needs. A test passes in fakes; production passes in real ones. The dependency became visible and soft.

Service locator: injection’s tempting cousin

A service locator also avoids new, but the class asks a global registry for its dependencies: const db = Container.get('Database'). This looks like DI but reintroduces the original sin — the dependencies are hidden again (the constructor no longer lists them), and the class is coupled to the locator. It is widely considered an anti-pattern in application code precisely because it hides what a class needs and only fails at runtime, not at compile time or startup.

The composition root

If classes no longer construct their dependencies, something must. That something is the composition root: a single place near the application’s entry point where the entire object graph is assembled — the only place that names concrete implementations. Everything downstream depends only on abstractions. Centralizing construction means there is exactly one spot to change wiring, swap implementations, or read off the whole dependency graph. A DI container automates this assembly, but the principle holds even with hand-wiring: keep construction at the edge, keep logic in the middle dependency-free.