Dependency Injection – Understanding DIP, DI, and IoC Theory

Architecturedependency-injectioninversion-of-controltheory

For about 2 months I've been reading everything I can find for these 3 topics and I'm not yet sure I got it.

  1. Dependency Inversion Principle. Means you should always only rely on interfaces and not on their implementations. If your class depends on any other class, that's bad, because it depends on that second class' details. If your class depends on interface, that's absolutely OK since this kind of dependence only means that your class needs something abstract that can do something specific and you don't really care the way it does it.

    Since P in "DIP" stands for "Principle", I should probably define it this way: Dependency Inversion Principle is a principle that requires all your code's entities to depend only on details they really need.

    By "details they really need" I mean interfaces for the simplest case. I also used the word "entities" to emphasize that DIP is also applicable to procedures and whatever else, not only to classes.

  2. Dependency Injection. It's only applicable to DI-enabled entities. DI-enabled entity is an entity which is "open" for configuring its behavior without changing its internals. There are 2 basic kinds of injection (when talking about classes):

    • Constructor Injection – is when you pass all the required "abstract details" to the object just by the moment it's about to be constructed.
    • Setter Injection – is when you "clarify" the required aspects after the object has already been created.

    So, the definition is probably like following: Dependency Injection is a process of passing the "abstract details" to the entity that really needs these details.

    By "really needs these details" I mean interfaces for the simplest case. The word "entities" is, as always, used to emphasize that DI is also applicable to procedures and whatever else.

  3. Inversion of Control. It's often defined as "difference between libraries and frameworks", as "writing programs the either way you did in procedural programming" and so forth. That the most confusing thing for me. I believe that main idea here is just about initiating any actions. Either you do something "whenever you want" (Procedural way), or you "wait" until someone asks you (IoC way).

    My Definition is: IoC is a property of your program's execution flow, when you don't do anything until they ask you to do it.

    It sounds exactly as "Hollywood Principle", but I believe that "Hollywood Principle" and IoC are both absolutely the same idea.

Do I understand it?

Best Answer

If you look at your three definitions, the distinction is subtle, but they essentially mean the same thing.

What it all amounts to is providing what the class needs (its dependencies) through parameters in it's constructor. That's all. There are numerous Dependency Injection frameworks out there that seek to formalize this process, but they all amount to the same thing.

Dependency Injection always seeks to provide only those dependencies that are needed, when they are needed.

Related Topic