A place for spare thoughts


Re: DI vs DIP vs IoC

Filed under: patterns — Ivan Danilov @ 06:59

Have just read blog post about the subject (in Russian).

I’m an absolute “fan” of definitions which “forgot” to define things and just trying to explain them with examples. Such as “it is when you have …”. Fabulous. And useless. I do agree with DIP description, partially agree with DI description and find IoC description plainly wrong.

Yes, sure, difference between a library and a framework is defined by who controls execution environment. IoC is related to that topic, but it is not this difference itself.

Inversion of Control is a principle that allows one part of code (often general and reusable) to communicate with another (more specific) without intimate knowledge of its implementation. It is an idea basically, and an “abstract” one in some sense.

There is a couple of concrete techniques that implement the IoC principle: callbacks, interface dispatch, dynamic call dispatch, virtual calls etc. One could remember typeclasses from Haskell. Even an abstract factory pattern may be seen as some sort of IoC, as it gives its client ability to construct instances of product without knowing its concrete class.

Sure, frameworks are using IoC almost always, but IoC doesn’t implies a framework by itself. When you call Win32 API function that takes a callback – you’re using IoC without any framework involved.

Now, Dependency Injection is one of aspects that allow to achieve IoC: if some code creates its dependencies itself (e.g. with direct calls of their constructors) – it definitely can’t be unknowing about details of their implementation. It knows precise type – indeed a very strong variant of coupling. Injecting such dependencies instead by some external entity is what implements IoC principle here. In other words, DI is one possible technique to achieve IoC.

IoC-container is a piece of software that allows applying and reusing different IoC techniques in your code. Usually a library. For example, Windsor container supports several types of DI, automatic typed implementation of abstract factories and some more. And with all of that it is obviously a pure library, not a framework.

Hence, IoC-container as a term is not “meaningless”. I’d rather say that defining IoC as key difference between library and framework is meaningless.

Finally, Dependency Inversion Principle is a guidance that dictates which is the most promising way to structure software. Namely, higher levels of abstraction should not depend on lower levels. For example, module responsible for publishing reports should not depend on sockets to send them. It is easy to imagine sending reports via email, file, web-service, printing or RSS, as well as formatting them in dozen of formats. Having knowledge about such low-level details makes code likely candidate for rewriting later.



  1. I never stated in my post that IoC is equals to framework or that a framework is the only way to achieve IoC. I clearly stated there that any Observer is an example of IoC as well.

    Comment by Sergey Teplyakov — 28/11/2014 @ 07:59

    • The most close to a definition is “Инверсия управления (IoC, Inversion of Control) – это достаточно общее понятие, которое отличает библиотеку от фреймворка” (translation: “IoC is a reasonably generic notion which differentiates library from a framework”). That is what I don’t agree with. Plus “IoC-container” meaninglessness outside of a framework context.

      Comment by Ivan Danilov — 28/11/2014 @ 08:04

      • Yep, this aspect differenciate a framework from the library, but the opposite is not true. I didn’t stated anywhere that the IoC technique is available only at frameworks. This is an aspect that differenciate any framework from a library, but there is a lot of other ways to achieve a IoC.

        Comment by Sergey Teplyakov — 28/11/2014 @ 08:09

      • OK, let me paraphrase: library can have or not have IoC, but a framework will employ IoC always, because otherwise there’s no way it can pass the control to other code. Is that what you’ve meant?

        I still consider it not a “differentiation” (because it is by definition pointing a characteristic by which two objects can be distinguished from each other, and as such it is symmetric logic relation, hence can’t be true only in one direction), but it is nitpicking.

        Comment by Ivan Danilov — 28/11/2014 @ 08:37

  2. > library can have or not have IoC, but a framework will employ IoC always, because otherwise there’s no way it can pass the control to other code. Is that what you’ve meant?
    Yep, this exactly what I meant!

    And this is a common differentiation. For instance, Martin Fowler used this as well: http://martinfowler.com/articles/injection.html. And I totally agree with Martin, that’s why I used this difference as an argument in my post.

    And I don’t think there is a symmetric logic relation here. If a framework implies IoC that doesn’t mean that IoC implies framework.

    Comment by Sergey Teplyakov — 28/11/2014 @ 08:50

    • Consider Ant or MSBuild as an example. It is clearly defines an execution environment for tasks that it calls. So, in this sense they’re frameworks for building which combine steps together and control their execution process. But their main functionality is only a direct call like “Execute()” (yeah, that is a simplification but nonetheless there’s no IoC).
      Or even runtime that executes a program (e.g. calls “main()” in case of C/C++) – it is in control of execution environment, but doesn’t use IoC.

      I read Martin there. In other article http://martinfowler.com/bliki/InversionOfControl.html he says that “it’s often seen as a defining characteristic of a framework”, but not more. I consider it rather a convenient shortcut that is correct _almost always_ rather than a conceptual thing.

      It is symmetric not in implication part certainly. If framework could be differentiated by its IoC usage from library – then library also could be differentiated from framework by its IoC usage. As I said, it is nitpicking 🙂

      Comment by Ivan Danilov — 28/11/2014 @ 09:16

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: