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.