SOLID Principles: Dependency Inversion Principle
Dependency Inversion Principle has a dramatic effect on your code base. It has the potential to decouple your code in ways that you never would have thought possible before. Using a good IoC container can make all the difference as well.
The best way to explain this principle would probably be an example. Let’s say you have a car like this
Notice the engine that belongs to the car. First of all, the car is actually creating the engine. This means that the car is tightly coupled to the engine it’s creating. Secondly, this creates a concrete coupling on the car to a specific kind of engine, the FourCylinderEngine.
A better solution would be to use Dependency Inversion. You should depend on an interface instead of a concrete class. Back in our example, our FoudCyclinderEngine looks like this
Notice how it implements Engine. That’s the interface our Car should be using. There’s one additional problem, though. Right now the Car is creating it’s Engine, but you can’t instantiate an interface, so what do you do? That’s the key to Dependency Inversion. You’re saying,
a Car does not depend on knowing about how to create an Engine
It just uses it. So the new Car class looks like this
So how does the engine get created? Obviously something is passing in the engine to the Car, but what? You need a new class. Maybe a CarManufacturer or something, which is responsible for manufacturing cars. Part of that responsibility would be putting an engine in a car.
Want more info? Check out this dime cast.