What is meant by 'Inversion' in Dependency inversion

Question

I am learning spring. I understood dependency injection. In some place I also see it called dependency inversion. I got why it is termed as injection but what is meant by "inversion"? Which dependency is it actually inverting?

Answer 1

Good question - the word inversion is somewhat surprising (since, after applying the DIP, the lower level dependency module obviously doesn't now depend on the higher level caller module, either - both caller and dependency are now just more loosely coupled through an additional abstraction).

Citing Robert C Martin's original source

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. ... Thus, the dependency structure of a well designed object oriented program is “inverted” with respect to the dependency structure that normally results from traditional procedural methods.

One point to note when reading Uncle Bob's paper on the DIP is that C++ didn't (and at time of writing, still doesn't) have interfaces, so achieving this abstraction in C++ is typically implemented through an abstract / pure virtual base class, whereas in Java or C# the abstraction to loosen the coupling would usually be through decoupling by abstracting an interface from the dependency, and coupling the higher level module(s) to the interface.

Edit Just to clarify:

"In some place I also see it called dependency inversion"

Note that Dependency Injection (DI) is ONE of the possible implementations to achieve the Dependency Inversion Principle (DIP) - the "D" in SOLID design principles, so DI and DIP are not entirely interchangeable.

Other DIP implementations include the Service locator pattern (which is nowadays often regarded as an anti-pattern); and Plugin.

Answer 2

Inversion: Inverting the dependency management from the application to the container(Spring for example).

Dependency Injection:

Rather than writing factory pattern, how about injecting the object directly in to the customer class. So let the customer class references the interface and we should be able to inject the concrete type in to the customer class. With this the customer class does not need to use the new keyword and is complete decoupled from the concrete classes.

So what's about the Inversion of control (IoC) ?

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.

Inversion of control as a design guideline serves the following purposes:

• There is a decoupling of the execution of a certain task from implementation.
• Every module can focus on what it is designed for.
• Modules make no assumptions about what other systems do but rely on their contracts.
• Replacing modules has no side effect on other modules.

For further information take a look at:

Design Pattern IOC and DI.

Design pattern – Inversion of control and Dependency injection.

A Practical Introduction to Inversion of Control.

Inversion of control (IoC) and dependency injection (DI) patterns in spring framework and related interview questions.

Answer 3

As best I understand it, use of the term "inverted" depends on the fact that an interface is considered a higher-level abstraction than the service that depends on it. What's being inverted is the direction of abstraction dependence: instead of depending on a lower-level thing, your service now depends on a higher-level thing.

Let's consider a simplified example.

• In a "bad" application, FooService depends on BarDatabase: our service depends on a database implementation. Notably, our service depends on a lower-level 'thing'.
• In a "good" application, FooService depends on DatabaseInterface, which in turn is implemented by BarDatabase. And since an interface is considered a high-level abstraction than a service, our service now depends on a higher-level 'thing'.

Now, in a sense, the directionality of dependency is unchanged. In practice, FooService still depends indirectly on BarDatabase. It's worth emphasizing that when we say that we've inverted the dependencies, we do NOT mean that BarDatabase now somehow depends on FooService.

We simply mean that, instead of depending on something lower down the ladder of abstraction, our service now depends on something higher up. We've "inverted" the direction our service needs to climb to obtain its dependencies.

I'll defer to widely available terrific explanations as to why this is the good thing, but the intuition is that depending on things more abstract than yourself makes you less tightly coupled with external things, which in turn is closely related to good stuff like encapsulation and separation of concerns.

References: What inverts in the dependency inversion principle?