Understanding the DIP, DI, IoC theory

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: DependencyInversion Principle is a principle that requires all your code's entities todepend only on details they really need.

By "details they really need" I mean interfacesfor the simplest case. I also used the word "entities" to emphasizethat DIP is also applicable to procedures and whatever else, not only toclasses.

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: DependencyInjection is a process of passing the "abstract details" to theentity that really needs these details.

By "really needs these details" I mean interfacesfor the simplest case. The word "entities" is, as always, used toemphasize 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'sexecution flow, when you don't do anything until they ask you to do it.

It sounds exactly as "Hollywood Principle", butI believe that "Hollywood Principle" and IoC are both absolutely thesame idea.