17

In many articles all over the web the terms Inversion of Control and Dependency Inversion Principle seem to be mixed up and used as synonyms (further confusion is enforced by the tools that are called "DI-Containers" and "IoC-Containers"). A Wikipedia article does a nice job trying to explain that IoC is not the same as DI:

inversion of control (IoC) describes a design in which custom-written portions of a computer program receive the flow of control from a generic, reusable library

So DIP is about having your modules depend on abstractions rather than concrete implementations.

And IoC is about giving control over your program flow to a separate module. And one of the things you can have this module do is resolve the dependencies at runtime.

This difference does seem fair, but I've never seen anyone mention any other applications of the IoC principle other than dependency resolving. The Wikipedia definition is quite broad, and it seems like you could do so much more with a module that has that can make calls into your custom code based on its configuration and some internal logic.

So, here are some questions that I can't quite figure out yet:

  • What is the actual relation between IoC and DIP? Does IoC always serve as the means of implementing DIP?
  • Why are tools for dependency resolving called both DI- and IoC-containers? This implies that DI and IoC are the same thing.

Note: This question is not a duplicate of What is the difference between DI and IoC, because the latter asks about Dependency Injection, not Dependency Inversion.

Community
  • 1
Andre Borges
  • 1,534
  • 1
  • 14
  • 15
  • Possible duplicate of [What is the difference between DI and IoC?](http://programmers.stackexchange.com/questions/131324/what-is-the-difference-between-di-and-ioc) – gnat Mar 03 '16 at 12:32
  • @gnat, no it's not, please see my edit – Andre Borges Mar 03 '16 at 12:34
  • agree, I missed that sorry – gnat Mar 03 '16 at 12:35
  • 2
    IMO, the simple answer is "they are the same". IoC is another name for dependency inversion and both are a way of achieving dependency injection. I see "dependency inversion" as a deeply unhelpful term as it is too easily confused with injection. So there's DI (injection) and IoC is a way of achieving inversion of dependencies/control via injection. – David Arno Mar 03 '16 at 13:00

1 Answers1

10

There is a great article on Martin Fowler's site that has a chapter specifically about the difference between DIP, DI and IoC. The gist of it (as copied from that site) is

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. To be sure, using DI or IoC with DIP tends to be more expressive, powerful and domain-aligned, but they are about different dimensions, or forces, in an overall problem. DI is about wiring, IoC is about direction, and DIP is about shape.

JDT
  • 6,302
  • 17
  • 32
  • 3
    _IoC is about who initiates the call_ - who intitates the call to what? If I write `ISomeInterface object = container.Resolve()` is that IoC or not? – Andre Borges Mar 03 '16 at 14:11
  • 2
    What you write is an implementation in the service locater pattern. This is also IoC. Not IoC is ISomeInterface object = new MyClass(). So the call that is meant is the "call to instantiation" (or who calls 'new'). – Sjoerd222888 Mar 03 '16 at 14:26
  • 1
    "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." That sounds like nonsense to me. Where's the inversion in that? He's describing dependency abstraction, not inversion. – David Arno Mar 03 '16 at 14:58
  • @DavidArno, are you saying we can't trust Martin Fowler's website? – holdenmcgrohen Mar 03 '16 at 18:53
  • @holdenmcgrohen, it's his opinions on things. Just because it's Martin Fowler, doesn't make it fact. He's wrong at times IMO, eg regarding the "anaemia data model". Other times, his very insightful. On this occasion I think he's wrong too as it doesn't make sense. – David Arno Mar 03 '16 at 18:58
  • @DavidArno, that sentence is not the whole picture. By introducing that abstraction, instead of the calling code needing a dependency on the server code, it takes a dependency on the abstraction. Then the server code implements and takes a dependency on that abstraction. Hence the direction of dependency is _inverted_. – Saeb Feb 26 '17 at 05:26
  • @AndreBorges That would be DI, but not IoC, since on IoC you'd have the framework inject it onto you, not you explicitly asking for it. – David Gomes Jan 03 '22 at 11:19