Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
Can you read code and write code the follows these design patterns? –  S.Lott Jul 20 '11 at 19:41
1  
Duplicate of stackoverflow.com/questions/6766056/dip-vs-di-vs-ioc It has now been answered. You can't expect to get an answer immediately. –  Mark Seemann Jul 20 '11 at 19:43
    
Please don't cross post on multiple Stack Exchange sites. It makes work for the moderators to clean up. –  ChrisF Jul 20 '11 at 20:00

1 Answer 1

up vote 5 down vote accepted

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.

share|improve this answer
    
So, how many entities do you propose? Just 1 for all these 3? Which 2 of my definitions are the same? –  loki2302 Jul 20 '11 at 19:28
    
Entities? I missed your third definition; they are all branches of the same tree. It's too bad we have to complicate concepts like this with lofty names like "Inversion of Control." –  Robert Harvey Jul 20 '11 at 19:29
1  
Yes, that's what I think. –  Robert Harvey Jul 20 '11 at 19:35
1  
I thought it was not just constructers but also providing what a class needed through property settings and methods? Although constructors were the preferred approach I believe. –  dreza Jul 20 '11 at 19:35
1  
@dreza: You can, of course, provide what a class needs through properties and methods, but providing your dependencies through the constructor is more in keeping with certain best practices, such as immutability. Consider what happens when you have multiple properties to set. Which ones do you set first? How do you handle validation? Are the property values interrelated? Setting it all in the constructor allows the validation to take place all at once, in the constructor. –  Robert Harvey Jul 20 '11 at 19:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.