I'm reading about design patterns. I know what this principle does.

High-level and low-level classes depend on abstractions. But why we say this is inversion?

  • 1
    this is explained in the very beginning of Wikipedia article on Dependency inversion principle: "conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are inverted... The principle inverts the way some people may think about object-oriented design, dictating that both high- and low-level objects must depend on the same abstraction..." – gnat Dec 27 '13 at 7:14
  • I don’t think that the already answered linked question is a duplicate of this question. Dependency inversion is not the same as inversion of control. From the IOC wiki page, “ The term is related to, but different from, the dependency inversion principle, which concerns itself with decoupling dependencies between high-level and low-level layers through shared abstractions.” – Jinglesting Nov 12 at 11:02

From Wikipedia:

In traditional programming, the flow of the business logic is determined by objects that are statically assigned to one another. With inversion of control, the flow depends on the object graph that is instantiated by the assembler and is made possible by object interactions being defined through abstractions. The binding process is achieved through dependency injection, although some argue that the use of a service locator also provides inversion of control.

Or in other words: in traditional, non-inverted control higher-level components depend on lower-level ones.

This has been demonstrated as a limitation, because high-level components lose the chance of working with more than an environment or low-level excessively specific components.

With inversion of control, the above paradigm is inverted. The high-level components are just abstract classes or interfaces and these are usually (and should be) declared in a package or assembly having no dependency on the code implementing them, and it's the implementation the code that's dependent on higher-level code (because the low-level code must implement a high-level interface or abstract class).

This is the inversion!

  • The question is about Dependency Inversion (en.wikipedia.org/wiki/Dependency_inversion_principle), not the Inversion of Control. Do you believe there is an inversion of dependency when DIP is applied? Would you care to explain exactly what dependency is inverted then? – UnclickableCharacter May 5 '13 at 15:08
  • @fnt I believe that IoC and DIP are related concepts. One is the implementation and the other the concept itself. By the way, double-check your link to Wikipedia. It almost says what I pointed out in my answer. Thanks. – Matías Fidemraizer May 5 '13 at 17:06
  • I would argue about the relation of these concepts as you define it, however, it is not the topic of current discussion. Since you consider one to be an implementation of another, I am still curious what is that dependency that is inverted with DIP. – UnclickableCharacter May 5 '13 at 18:17
  • @fnt I'll take a look at your concern in some days, I'm absolutely busy now to discuss this, sorry :( – Matías Fidemraizer May 5 '13 at 18:26
  • There is no inherent limitation in "non-inverted" designs. The limitation arises when inversion of control is needed: a need for plug-ins implemented in third party code, for example. Other "limitations" are mostly fictions, limitations in a fictional future design. – Frank Hileman Mar 16 '17 at 19:11

Quote of Bob Martin in his original article on the topic:

One might question why I use the word “inversion”. Frankly, it is because more traditional software development methods, such as Structured Analysis and Design, tend to create software structures in which high level modules depend upon low level modules, and in which abstractions depend upon details. Indeed one of the goals of these methods is to define the subprogram hierarchy that describes how the high level modules make calls to the low level modules. Figure 1 is a good example of such a hierarchy. Thus, the depen- dency structure of a well designed object oriented program is “inverted” with respect to the dependency structure that normally results from traditional procedural methods.

So as I understand, having the inversion priciple in place makes the high level policy described in terms of abstraction rather than concrete utility components. And from the point of view of the high level module the abstract policy remains stable. Any changes of the low level implementations do not force the high level module to change.

The term 'inversion' distinguishes the approach from the traditional model.


I'll put a direct example of the inversion of control.
Imagine you have a Television class:

class Television {
    private Button powerButton;

    public Television() {
        this->powerButton = new Button();

    function turnOn() {

As you can see Television is tightly coupled with the Button class, a low-level component. That means Television depends on the button class to be turned on.

Inversion of control dictates that Television must not depend on the Button class. That is: "Television must not instantiate a Button class"

The solution would be something like this:

class Television {
    private ISomethingThatTurnsOnTV thisTurnsOnTV;

    public Television(ISomethingThatTurnsOnTV somethingThatTurnsOnTV) {
        this->thisTurnsOnTV = somethingThatTurnsOnTV;

    function turnOn() {

Now Television doesnt know if its a button, a remote control or a human gesture the thing that is turning the television on. And the Button must implement the interface ISomethingThatTurnsOnTV, that is a high-level component.

So we went from:

Television ---- depends on ----> Button


lowLevel -------------------------highLevel
Button -----depends on --------> ISomethingThatTurnsOnTV

and Television does not depends on Button anymore :D

  • 2
    This example only goes so far, what you are missing is that the Television must also implement an interface, something that defines that it is an object that is able to be turned on. Then, you would be able to have the function turnOn() read like this: function turnOn() { this->thisTurnsOnTV->turnOnTV(this); } and anything that can turn on something can turn on anything that is able to be turned on. But in your example how is the object that turns on the Television able to interact with the Television if it has no reference to it? – RibaldEddie Dec 26 '13 at 20:49
  • @RibaldEddie So far no one here was able to clearly explain what are the dependency they get rid of or invert with DIP – UnclickableCharacter Feb 4 '14 at 8:36

The problem is that so-called "Dependency Inversion Principle" is poorly named and defined. While the definition was clarified by its author afterwards, the name is a total misnomer. There are no dependencies which are inverted when this principle is applied.

  • 1
    who is "author" you talking about? and why you think it is a total misnomer? – gnat Dec 26 '13 at 20:44
  • The author of the term - Robert C. Martin. Why I think it is a misnomer is explained in the comment you are replying to. – UnclickableCharacter Dec 27 '13 at 6:25

Traditionally, your dependencies would descend downwards in your application.

That is, you would have a high level class A, which depends on a lower level class B.

Consider a car. In traditional programming, your car object would depend on your steering wheel object, which would depend on your two front wheel objects. This means that if your wheels change, your steering wheel class needs to change, and your car class might even need to change.

Car -> SteeringWheel -> Wheels

Dependency inversion gets rid of these dependencies and adds two new dependencies:

Car -> ISteeringWheel
SteeringWheel implements ISteeringWheel
SteeringWheel -> IWheels
Wheels implements IWheels

This change means that we can now test the car independently from the SteeringWheel, the SteeringWheel independently from the wheels. We can also change the implementation of the Wheels or the SteeringWheel without needing to make changes to one of the parent classes.

This makes for a much more flexible architecture and helps us ensure that the other SOLID principles (particularly the SRP) are not violated.

The inversion is not a reversing of the dependencies (after all, the Wheels are not dependent on the SteeringWheel now) but is turning the dependencies 90 degrees to a new abstraction. Inversion is possibly a poor choice of word. A more descriptive choice might be "Dependency Right Angled Turn". But that's not as catchy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.