DIP vs. DI vs. IoC [closed]

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.

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.
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.
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?

回答1:

My take on it is this: DIP is the principle that guides us towards DI. Basically, loose coupling is the goal, and there are at least two ways to achieve it.

Dependency Injection
Service Locator

However, Service Locator is an anti-pattern and has nothing to do with the DIP. DI, however, is the correct application of the DIP.

The relationship between DI and IoC has been explained before.

BTW, when talking about DI and loose coupling, I find the terminology laid out in Domain-Driven Design the most applicable. Basically, Services are the only kinds of objects subjected to DI.

回答2:

My 20c, start coding. You probably have at least a rough idea of how it works. Coding a proof of concept (POC) is going to be a great way to see how things fit together and work at dev and run time. Reading will only take you so far, doing will really help make it click.

If you don't know where to start, most blog posts about DI have simple examples that you can run up. Don't get stuck on which framework to use (Unity, Spring, Castle Windsor etc) because it really doesn't matter for a POC.