Difference between "Inversion of Control", "Dependency inversion" and "Decoupling"

I'm reading theory about dependency inversion and decoupling and I can't see the difference between the two.

Dependency inversion talks about decoupling functional components so that higher level components don't depend on lower level components.

Decoupling talks about the same thing and how to achieve it. But then we have IoC Containers that mess things up even further. Why aren't they rather called Dependency Inversion Containers or even better Dependency Injection Containers, because they serve runtime coupling of independent components?

Then we have Inversion of Control. It's basically the same thing as Dependency Inversion isn't it? Why are there three terms that describe the same thing? Or am I blind?

1. What is the difference between the three?
2. What does IoC have to do in IoC Containers?

Decoupling is a very general principle applicable in many fields. Dependency inversion is a specific form of decoupling where you decouple the higher levels of your system from the lower levels by separating them into libraries and using interfaces. This allows you to replace lower level parts of your system without major rework.

For example, instead of the higher level parts of the system creating concrete instances of the lower level classes, an IoC container can be used to decouple how objects are created.

Inversion of control is a design principle used by framework libraries that allow the framework to regain some control from the application. I.e., a windowing framework may call back into application code when certain user interface events occur. Martin Fowler uses the term Hollywood Principle as in Don't call us, we'll call you. Decoupling is an important part of inversion of control.

But what has an IoC container to do with inversion of control? To quote Martin Fowler:

> Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.

(Note that Martin Fowler talks about dependency injection, not dependency inversion.)

An IoC container helps to implement dependency injection and perhaps a better term would be dependency injection container. However, the IoC container name seems to stick. Dependency injection is an important component in dependency inversion, but the use of IoC containers for dependency injection can be confusing as inversion of control is a broader and more generic principle.

You point out that the naming isn't very consistent but that shouldn't be a big surprise as these terms have been independently invented and used even though they overlap.

Dependency Injection achieves Decoupling using Inversion of Control.

I find the following explanation from DIP in the Wild article on martinfowler.com straightforward to understand (here DI = Dependency Injection, DIP = Dependency Inversion Principle, IoC = Inversion of Control):

> DI is about how one object acquires a dependency. When a dependency is > provided externally, then the system is using DI. IoC is about who > initiates the call. If your code initiates a call, it is not IoC, if > the container/system/library calls back into code that you provided > it, is it IoC. > > DIP, on the other hand, is about the level of the abstraction in the > messages sent from your code to the thing it is calling. (...) DI is about > wiring, IoC is about direction, and DIP is about shape [of the object > upon which the code depends].

Dependency inversion: Depend on abstractions, not on concretions.

Inversion of control: Main vs Abstraction, and how the Main is the glue of the systems.

These are some good posts talking about this:

https://coderstower.com/2019/03/26/dependency-inversion-why-you-shouldnt-avoid-it/

https://coderstower.com/2019/04/02/main-and-abstraction-the-decoupled-peers/

https://coderstower.com/2019/04/09/inversion-of-control-putting-all-together/