Dependency Injection Basics

Dependency injection means a class is given the objects it needs instead of creating them itself. Instead of a report service calling new to build a data source, the data source is passed into the constructor. The class then depends on a contract rather than on a construction detail.

It matters because of what it makes possible. The class can be handed a different implementation without being changed, which is how you support a real one and a fake one in the same codebase. It can be tested without the real infrastructure, so the test runs in milliseconds and never fails because a database was busy. And the dependency becomes visible in the class's signature, so a reader can see what it needs without reading its body.

There is a second, quieter benefit. When a class builds its own collaborators, the construction of the whole object graph is hidden in the middle of the code, and it grows as new requirements appear. Injecting instead means the wiring lives in one place, usually a composition root, where the entire structure of the application can be read at a glance.

The trade-off is that the wiring code has to live somewhere, and someone has to write it. That is real work, but it is work that would have happened anyway, and doing it explicitly tends to produce a better answer.

Constructor injection is the default. A dependency passed through the constructor is final, so the object is fully formed when it becomes usable and there is exactly one place where its requirements are stated. A class with five constructor parameters is telling you it has too many responsibilities, which is useful information.

Setter injection fits optional or genuinely mutable dependencies, such as a configuration value that can be changed after construction. It is also the traditional choice in frameworks that create objects for you and then populate them. The cost is that the object exists in an incomplete state before the setter runs, and a caller who forgets the setter gets a half-configured object with no compiler warning.

Method injection suits dependencies needed for one operation only. Passing a logger or a callback into a single method keeps it out of the object's lifetime entirely, which is usually the clearest choice when the dependency is not part of what the object is.

The rule to give an interviewer is that the dependency's lifetime should match the way the class is meant to be used. If it is essential, require it in the constructor and make it final. If it is genuinely optional, allow it to be set later. If it belongs to one operation, pass it to that operation.