Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
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
add comment

migrated from stackoverflow.com Mar 23 '13 at 9:09

This question came from our site for professional and enthusiast programmers.

4 Answers

up vote 4 down vote accepted

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!

share|improve this answer
    
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? –  fnt 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. –  fnt 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
add comment

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() {
       this->powerButton->turnOnTV();
    }
} 

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() {
       this->thisTurnsOnTV->turnOnTV();
    }
} 

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:

highLevel-----------------------lowLevel
Television ---- depends on ----> Button

To:

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

and Television does not depends on Button anymore :D

share|improve this answer
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 –  fnt Feb 4 at 8:36
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
    
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. –  fnt Dec 27 '13 at 6:25
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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