2

IoC = Inversion Of Control

DIP = Dependency Inversion Principle (D in S.O.L.I.D.)

IoC == DIP? I think so, is true.

The world of building software is already so messy, why so many words to say the same thing?

(I know DI (Dependency Injection) and it is different of DIP and IoC)

Update:

According to the answers, then we can say that: (DI) + (IoC) = (Dependency Inversion Principle) ?

Acaz Souza
  • 8,311
  • 11
  • 54
  • 97
  • 1
    Kinda related: http://stackoverflow.com/questions/7099406/what-is-the-real-difference-between-bastard-injection-and-poor-mans-injection/7102651#7102651 – Mark Seemann Sep 07 '11 at 07:07
  • 1
    The way I usually put it is that the DIP is the underlying principle that guides us to implement DI, which applies IoC to the domain of dependency management. – Mark Seemann Sep 08 '11 at 12:00

2 Answers2

7

Inversion of Control is the generic term. Dependency Injection is a specific type of IoC.

See Inversion of Control Containers and the Dependency Injection pattern.

The Dependency Inversion Principle is a guideline, while the other terms are descriptive of techniques. (IoC can be used to describe a principle as well, so this can be confusing.)

Used in a sentence:

Sue followed the Dependency Inversion Principle by using Dependency Injection in the constructor of her class and creating instances with an Inversion of Control container.

Update:

I do not feel that (DI) + (IoC) = (Dependency Inversion Principle) is accurate. That's like saying (Apple) + (Food) = (Good Nutrition). Each term has a specific meaning.

TrueWill
  • 25,132
  • 10
  • 101
  • 150
  • 2
    +1 although a container targets DI, so the correct name would be "DI Container". If you accept that IoC is a general term (and I agree), there's no such thing as an "IoC Container". – Mark Seemann Sep 07 '11 at 07:04
  • 1
    To me, *inversion of control* always had a specific meaning, namely that the *flow of control* between methods is inverted in a *framework*, where client code gets called by the framework rather than calling the framework API. With a *library*, OTOH, the flow is not inverted as client code directly makes calls to library classes/methods. IMO, this term was inappropriately used by the initial "IOC container" proponents. – Rogério Jan 13 '12 at 18:33
6

I don't think you're going to get an authoritative answer on this one because the term "IoC" is kind of overloaded and to say "the one true meaning of IoC is..." is kind of pedantic. But I'll share my opinion anyway :)

Dependency Inversion is about depending on an abstraction. Consider a HelloWorld class that depends on an IStringWriter, and an implementation class ConsoleStringWriter.

Inversion of Control is when the framework/infrastructure invokes application code, rather than the other way around. For example, when a user closes a WPF app, you don't call the framework, it raises an event that you can subscribe to.

They are often combined. For example, Hibernate depends on the abstraction defined by its Interceptor interface in order to implement IoC. From an Interceptor's point of view, control is inverted - Hibernate calls the Interceptor. Another example you see all over is IHandle<T> where T is an Event or a Command or a Message - the infrastructure calls the handler at the right time.

Its confusing because we call them "IoC containers", but you can do DI without doing IoC. If you inject a ConsoleStringWriter into a HelloWorld I don't really think of this as IoC because there is no "framework" or "infrastructure". But that's because Hello World is trivial - as an application becomes more complex the need for IoC increases.

See also this question and accepted answer.

Community
  • 1
  • 1
default.kramer
  • 5,943
  • 2
  • 32
  • 50
  • +1 I would also differentiate Dependency Injection, which is the act of fulfilling dependencies defined per the Dependency Inversion Principle. – Bryan Watts Sep 08 '11 at 04:36