Posted by: jsonmez | November 13, 2010

Basic to Basics: What is Dependency Inversion? Is it IoC? Part 1

Today we are going to talk about one of the most confusing topics of all and see if we can unravel the mess of Dependency Inversion, Inversion of Control and Dependency Injection.

It’s not completely important that we understand the specifics of each of these names, because many people end up using them interchangeably.  It’s pretty unlikely that we are going to correct all that in this blog post.

What is important is that we understand the concepts and ideas behind each of these topics and understand what architectural problems each one is trying to solve.

Today, we are going to focus on Dependency Inversion and get a little bit into inversion of control.


Dependency inversion is the root

It all started with this simple concept introduced by Uncle Bob in his article in the C++ Report of May 1996, The Dependency Inversion Principle.

If you have the time to read through that article, do yourself a favor and do it.  You don’t need to know much C++ to understand it, and it really sheds a light on the problem Bob was trying to solve.

Bob talks about this principle in his excellent book, “Agile Software Development, Principles, Patterns, and Practices, and Agile Principles, Patterns, and Practices in C#”

This principle is actually very simply stated:

  1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
  2. Abstractions should not depend upon details. Details should depend upon abstractions.

I think this concept is easily misunderstood and misapplied, because the reason why we apply this principle is often neglected.

If you are familiar with IoC and Dependency Injection, you can see how both are based from this definition of Dependency Inversion.

What problem does dependency inversion solve?

Dependency inversion solves the problem of higher level modules being dependent on and coupled to the interfaces of lower level modules and their details.

Let me give you a real world example of a current problem that could be solved by dependency inversion.

Take a look around your house and count up all the devices that have batteries that must be charged somehow.

Things like:

  • Digital camera
  • Cell phone
  • Camcorder (flip cam)
  • Wireless headphones
  • Game controllers

What do all of these things have in common?  They don’t have a charging interface in common.  Some use micro-usb, some use mini-usb, some use their own funky plug.

So as a result, you can’t just have one thing that charged all your devices.  You have to have a different thing for each device.  Your home’s “charging mobile devices module” is dependent on the device.  If you change your cell phone, you need a new charger.  If you upgrade your camera, you need a new charger.

The dependency is going the wrong way.  Lower-level appliances are defining the interface that your home has to use to charge them.  Your home’s charging capability should define the interface the devices have to use.  The dependency should be inverted.  It would make your life a lot easier.

Let’s look at one more example of a place where I would bet dependency inversion is used.  Now, I don’t know about Walmart’s IT structure, but I would venture to guess that when they receive invoices from all of their many distributors the invoices come in the file format that Walmart specifies and not the other way around.

I would bet that Walmart specifies the schema for all of the data it receives from its many business partners.  Let’s assume they do.  In this case they have inverted the dependency, actually they have inverted the control.  Instead of their vendors controlling their interface, Walmart controls the vendors through their interface.

What this means is that every time the vendor changes their internal system they have to still conform to Walmarts interface instead of Walmart having to make changes to accommodate each vendors changes to their format.

To be continued

In my I am going to actually give a code example of dependency inversion, address unit tests and finally answer the question of whether dependency inversion is the same thing as inversion of control.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.


  1. A useful example would be petrol stations. Renault, Mitsubishi, and even Maserati all have the same fuelling ‘plug’. If a car has a different plug, you wouldn’t be able to fuel it anywhere. If a petrol station has a different plug, nobody would fuel up there simply because they can’t.

    This is an interface where neither car nor petrol station are dependant upon each other; they only depend on conformity.

    Another useful example is USB. Here, again, everybody supports the same interface. It even has versions where everybody who supports USB3 also supports USB1.

    Aren’t these examples for the best way to have dependencies?

    • I agree, those are good examples, but in any of the examples, there is always someone dictating the interface. The gas station may not dictate it, but the bigger entity does.

      In both those cases it is a committee of sorts. But I do see what you are saying. Better to have both the the depend on the interface than to have either depend directly on each other. Which I agree with most of the time.

  2. […] to Basics: What is Dependency Inversion? Is it IoC? Part 2 In my previous post on dependency inversion, I talked about what dependency inversion is and gave some examples in the real […]

  3. […]… […]

  4. […] covered much of the reasoning in my post on dependency inversion, but there are some important points that specifically relate to interfaces in programming that I […]

  5. Just dicovered your blog. Really cool stuff. Keep them coming

    • Thanks! Will do!

  6. You are an excellent writer. I came to your blog to read the post about TDD being hard. I was so impressed I randomly clicked on this post. Again, really impressed. I will now read everything else.

    • Thanks so much for the compliment. Encouragement like this make it all worth it.

  7. Really some very nice explanation.

    You just explained how ‘Dependency inversion’ resolves the problem of higher level modules being dependent on and coupled to the interfaces of lower level modules and their details.

    I have a couple of questions:

    1. How to decide whether a module is higher-level or lower-level.
    2. How can one decide whether one should use ‘Dependency Inversion’ or an ‘Adapter’

    • Hi Rahul,

      You can decide whether or module is higher-level or lower-level based on its responsibilities and composition. Higher-level modules usually consist of the lower levels. It is also the level of abstraction. High-level modules are built on top of the lower-level ones. (Sorry, I can’t think of a better explanation at this point.)

      I don’t believe that dependency inversion and adapter are mutually exclusive.

  8. […] What is dependency injection. : […]

  9. Reblogged this on Nathan.


  11. John,
    I need help in using Dependency Injection with ASP.NET web forms. I am building the application using MVP pattern. Any pointer would be of great help.

  12. Awesome explanation and use of real world example with chargers.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: