Dependency Injection & IoC

Imagine an OrderService that needs to send a confirmation email. The quick way is to reach for new EmailSender() right inside the constructor. It works on day one, but you've quietly welded the two classes together: OrderService now requires that exact EmailSender, with its exact configuration, forever.

That tight knot causes real pain. You can't swap EmailSender for an SmsSender without editing OrderService. You can't write a fast unit test, because every test now sends — or tries to send — a real email. And you can't reuse OrderService in a context that needs a different sender. The class is doing two jobs: its own logic and deciding how its tools get built.

Dependency Injection (DI) flips that around: instead of a class creating the things it depends on, those dependencies are passed in from the outside. OrderService simply declares "I need something that can send messages" and trusts that someone hands it a ready-made instance.

There are three common ways to inject a dependency. Constructor injection passes it as a constructor argument (new OrderService(emailSender)) — the most common and safest, since the object is fully wired the moment it exists. Setter injection assigns it through a property or setter after construction. Parameter injection passes it straight into the one method that needs it. In every case the key shift is the same: the class receives its collaborators rather than manufacturing them.

Inversion of Control (IoC) is the broader idea that DI is one example of. Normally your code is in charge: it decides when to create objects, how to wire them together, and what runs next. With IoC you hand that control to an external party — usually a framework or an IoC container — and let it create and connect your objects, then call into your code at the right moments.

This is often summed up as the Hollywood Principle: "Don't call us, we'll call you." You don't reach out and assemble the world; you declare what you need, and the framework supplies it and drives the flow. Dependency injection is simply IoC applied to the specific question of where dependencies come from.

An IoC container (sometimes called an injector or DI container) is a registry that knows how to build your objects. At startup you tell it the rules — for example, "when anything asks for a MessageSender, give it an EmailSender." From then on, whenever the container creates an object, it inspects what that object needs, builds those dependencies first (recursively), and injects them in.

So when you ask the container for an OrderService, it sees the constructor wants a MessageSender, looks up the rule, constructs an EmailSender, and passes it in — all automatically. The picture below shows this in motion: the Container (the injector) builds a Service and supplies it to the Consumer, rather than the consumer doing new itself.

The headline benefit is testability. Because dependencies come from outside, a test can inject a fake or mock MessageSender that records calls instead of sending real messages — so your tests run fast, offline, and deterministically. You verify OrderService's logic without ever touching a mail server.

The other wins follow naturally. Implementations become swappable: switch from email to SMS by changing one container rule, not the business logic. And the whole system stays at looser coupling — classes depend on abstractions, not on concrete constructors. This is exactly the Dependency Inversion principle from SOLID: high-level code shouldn't depend on low-level details; both should depend on a shared interface, which is precisely what DI lets you arrange.

DI is not free. It adds a layer of indirection: to understand what actually runs, you may have to trace through container configuration rather than reading a straight line of code. Heavy containers can feel like magic — objects appear fully assembled and it's not always obvious where, or why, a particular implementation was chosen. New team members often find the wiring harder to follow than a plain new.

It's also easy to over-use. Not every collaborator needs to be injectable; a small, stable value type or a pure helper can just be created directly. Reserve injection for the dependencies you genuinely want to swap, fake, or configure from the outside.