What exactly is Inversion of Control

Possible Duplicate:
What is Inversion of Control?

I understand what Dependency Injection (DI) is (I think!). It's basically the satisfying of dependencies that an object may have. I try to think of the code I write when using DI as service oriented and I define my code as using other services.

However, I'm currently wondering what it is exactly that we're inverting the control of, when using IoC. It's a fairly vague term and it could mean a couple of things.

But, I think it's the responsibility of creating the object (and therefore satisfying dependencies using DI) which is handled by the IoC framework.

It is still the responsibility of the application to ask for objects (ie - services) that it uses, the distinction being that it doesn't know (or care) how to create it. So, why is service locator considered an anti-pattern if all it's doing is asking for a service?

Have I got that correct? Or does it mean something else. Also, have I got the responsibilities of DI and IoC separated correctly? If I have then an IoC framework cannot function without a DI framework. Or is DI just a feature of IoC frameworks?


Dependency injection generally means passing a dependent object as a parameter to a method, rather than having the method create the dependent object. What it means in practice is that the method does not have a direct dependency on a particular implementation; any implementation that meets the requirements can be passed as a parameter.

Inversion of control simply recognizes that the dependency relationship is reversed. Instead of A depending on B by way of creating, implementing, or calling it directly, A receives B as a parameter, and is no longer responsible for B in any way.

Implementing parameter types as interfaces simplifies the process, and generalizes it, but it's not strictly necessary.


Inversion of control is a general pattern. Dependency injection is one use of that pattern. For more information, this article by Martin Fowler, in particular the section titled "Inversion of Control".

A lot of people now avoid the term "inversion of control" for DI because the inversion is compared with the way people did things before dependency injection became common. If you're now used to dependency injection, or are one of the people lucky enough to think that way from the beginning, then trying to figure out what's being inverted is just confusing.


Inversion of Control basically means that the application code doesn't care from where the parts it needs come.

You can achieve IoC via the various flavors of dependency injection.

As opposed to where in the Java world, a wrapper might ask for a resource by name via jndi. In that case the code is asking for it needs, as opposed to having it provided.

You said "It is still the responsibility of the application to ask for objects (ie - services) that it uses, the distinction being that it doesn't know (or care) how to create it."

I dont think that is true; components don't ask for other components. Dependencies are injected from a higher level, which is a different semantics. And that is the IoC.

链接地址: http://www.djcxy.com/p/14430.html

上一篇: 什么是控制反转的正式定义?

下一篇: 什么是控制反转