Dependency Injection & Inversion of Control

The smell: a class that `new`s its own dependency

Here is the trap, and almost everyone writes it first. A class builds the concrete thing it needs inside itself:

class Car {
  private engine = new PetrolEngine();   // ⚠️ car builds its own engine
  private wheels = new Wheels();          // ⚠️ ...and its own wheels

  drive() {
    this.engine.start();
  }
}

Those new lines look harmless, but the Car has just taken on a second job it never wanted: manufacturing its own parts. That quietly causes two real problems. You can't swap a part — the day you want an ElectricEngine, you have to open Car and edit it, because the petrol engine is hard-wired inside. And you can't test it in isolation — every test of Car now spins up a real engine, because the car insists on building the real one. The car is welded to specific parts it should never have cared about.

The fix: inject the dependency through the constructor

Stop building parts inside the car. Declare what the car needs as parameters and let them be passed in. This is constructor injection — the most common, most honest form of DI:

class Car {
  constructor(private engine: Engine, private wheels: Wheels) {}  // handed in

  drive() {
    this.engine.start();
  }
}

// somewhere at the edge of the app, the assembler builds and wires:
const car = new Car(new ElectricEngine(), new Wheels());

Notice what just happened. The Car no longer says new anywhere. It receives an Engine and uses it. Whoever creates the car decides which engine goes in. Want electric? Pass an ElectricEngine. Want a fake for a test? Pass a FakeEngine. The Car class is never reopened. As a bonus, the constructor now lists every dependency up front — you can see exactly what a Car needs just by reading its signature.

The inversion: who is in control of building the parts?

Look at the direction of control. Before, the Car reached down and built its parts — control lived inside the car, and the build arrows pointed down and outward from it. After, an external assembler (often just your main()) builds the parts and passes them up into the car's constructor. Construction control moved from the object to the outside. That reversal — the object no longer controls how it is assembled — is the Inversion of Control. DI is the mechanism that carries it out.

The composition root: where the wiring lives

If objects no longer build their own dependencies, something must. That place is the composition root — a single spot near the entry point of your app (main(), a startup file) where you construct the concrete pieces and wire the whole object graph together. Keeping the wiring in one place at the edge means the rest of your code stays free of new and free of construction concerns.

How DI, IoC, and DIP relate

• IoC (Inversion of Control) is the broad principle: an outer assembler or framework controls construction and flow, not your object. “Don't call us, we'll call you.” DI is one kind of IoC (the kind about construction).
• DI (Dependency Injection) is the technique: pass dependencies in from outside instead of building them with new. It's the most common way to achieve IoC over object construction.
• DIP (Dependency Inversion Principle) is a separate, related idea — the D in SOLID — about which direction dependencies should point: toward abstractions (interfaces), not concrete classes. DI is how you usually deliver a DIP-friendly design: you inject an interface, and the assembler chooses the concrete implementation. You can do DI without DIP (inject a concrete type) and aim at DIP without a container — but in practice they travel together.

Inject the dependencies that vary or talk to the outside world

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

• External services — databases, payment gateways, email/SMS providers, an HTTP client to another team's API. Inject them so you can stub them in tests and swap providers in production.
• The clock and randomness — inject a Clock and a RandomSource so tests can pin time and seeds instead of being flaky.
• Things you want to fake in a unit test — if you can't test a class without standing up real infrastructure, that dependency wants injecting.
• Configuration & policy choices — inject the strategy (which algorithm, which storage backend) so the choice is made once, at the composition root, not scattered through the code.