Dependency Inversion Principle

Dependency Inversion Principle

The Dependency Inversion Principle brings us to the conclusion of studying the five solid design principles which hail from Bertrand Meyer, Barbara Liskov, Robert Martin, and Tom DeMarco, among others. If these five articles have your head spinning, fear not. We’re dealing with abstractions, and abstractions can start to play tricks on your mind after a while. Learning about these design patterns are a great way to practice your craft. We’re all trying to tame the unlimited amount of complexity that comes along with programming computers. All of these principles attempt to make things easier to reason about, and limit the size of any one module. Let’s have a look at the final principle in this solid series now.

What Does The Dependency Inversion Principle Mean?

Let’s start with the formal definition, and then review.

1. High-level modules should not depend on low-level modules. Both should depend on abstractions.


2. Abstractions should not depend on details. Details should depend on abstractions.

How about Laymans terms please?

What the Dependency Inversion Principle means is that software should not have dependency in a one way manner. Uncle Bob always refers to this as the direction in which arrows point between modules. For example, if you have three modules and they all point from the left to the right in a high level to low level manner, then you do not have dependency inversion. Instead, we should have high level modules that depend on an abstraction (interface) and low level modules that also depend on the same abstraction. This way, not only can you swap out and reuse the low level modules, but you can also swap out and reuse the high level modules as well. Check out the two most common examples used to describe how dependency inversion works.

The Handle and Tip Dependency Inversion Example

dependency inversion example one
Right here we have an example of a high level module (The Handle) and a low level module (The Tips) that depend on the same abstraction (The hexagonal shape). Not only can you change out tips as you like (low level modules), you can also change out the Handles (high level modules) as you like as well. This is true dependency inversion. Here is my best stab at implementing this in code. If you have a better solution, please do let me know so I can update it (contact @vegibit)

Cool! No matter which handle or tip we choose, as long as they make use of the hexagon shape of our interface, we can interchange and plug and play at will.

The Power Plug Dependency Inversion Example

dependency inversion example two
Another example of the dependency inversion principle is that of the standard power plug. A house has a means, or an interface to provide power, and that is by way of the standard wall socket outlet. We have all kinds of electronic gadget makers that want to sell you their wares, but they depend on electricity to work. The bright folks that build these boxes do not leave it up to you to figure out how to get power into those devices. They are smart enough to conform to the interface that they will need to use. The house says, I will provide power, but I will only do it through this interface. The gadget makers gladly implement that interface, and now you are free to plug in your Xbox, Playstation, Nintendo, iPhone charger, refrigerator, Ultra HD Tv, and more into the given interface (the power outlet).

Who Owns The Interface?

Uncle Bob talks about this concept as a plug in architecture, where modules can be interchanged via a plug in system. Now the dependency inversion principle does invert the way we might thing about dependency, and it makes both low level and high level modules interchangeable. At the end of the day though, someone usually owns the interface. In one of his presentations, he eloquently puts it as “who stands to get screwed if this interface changes?” or “Who is really in control here?” It is a fascinating topic, and one that kind of reminds me of how Lawrence Lessig thinks about software and code.


More Resources on Solid Design in Object Oriented Programming

Do check out these fine resources that helped support the concepts in this article.


Bob Martin SOLID Principles of Object Oriented and Agile Design

Anthony Ferrara helps you to Grasp SOLID

The Dependency Inversion Principle Summary

This wraps up our informal study of not only the Dependency Inversion Principle, but also of the entire suite of concepts in the solid realm. It is worth noting that these are not hard rules, but design philosophies and patterns to guide us along. I really like the way Anthony Ferrara sums it up in his talk. At the end of the day, our goal is to provide business value, and uses Hockey as an analogy. He compares this to a clean goal (solid) vs a dirty goal (spaghetti) in hockey. When the clean goal happens, we all marvel at the beauty and finesse with which the goal was scored. We might see it on the highlight reels much like we might blog about beautifully designed code. The dirty goal is no less valuable! Even though the player may have tripped over himself and landed face first into the ice, somehow, the puck was released from his stick and was able to slip by the goalkeeper. It may have not been pretty, it might have been downright ugly. The truth is however, that ugly goal may have won the game. In software, you might have some dirty goals (like we all do), but if it is scoring goals – you’re still winning.