Table of Contents
I know many people will see the title and think: "Ah… it's .NET, maybe next time." I don’t blame you—I used to be one of those who ignored anything related to .NET. While it’s an interesting phenomenon that younger developers tend to avoid .NET, I’ll save that discussion for another time.
That said, even if you have zero knowledge of .NET, you’ll still be able to understand 99% of this blog post. So, if you have about 30 minutes and want to learn about dependency injection, grab a coffee, find a comfy spot, and let’s dive in!
You’ve probably heard terms like dependency inversion and inversion of control before. Let's break these down first.
Normally, when we think of dependencies, we imagine something like this:
So, naturally, we create separate classes for Car, Engine, and CoolingSystem, and have Car reference Engine, which in turn references CoolingSystem. While there’s nothing wrong with this approach, this direct dependency structure makes scaling difficult. If you change the CoolingSystem, you might have to change Engine, which could then affect Car.
This is where dependency inversion helps. Instead of having Car directly reference Engine, it should reference an Engine interface—an abstraction of Engine (See diagram below).
Wait… Abstraction? Interface?
Think of an abstraction as a blueprint for a software component. It doesn’t contain implementation details, only the structure.
For example, an Engine abstraction might define a
StartEngine()method, but it doesn’t specify how the engine starts. The actual implementation is handled by theEngineclass.In code, we use interfaces or abstract classes to create these abstractions.
IoC is a design principle that reverses the flow of control in software. Instead of your custom code calling a framework, the framework calls your code when needed.
A common example is event-driven programming, where developers write business logic for handling events, but the event dispatching is managed by the framework.
This concept plays a key role in dependency injection, which we’ll explore next.