Inversion of Control vs Dependency Injection
According to the paper written by Martin Fowler, inversion of control is the principle where the control flow of a program is inverted: instead of the programmer controlling the flow of a program, the external sources (framework, services, other components) take control of it. It's like we plug something into something else. He mentioned an example about EJB 2.0:
For example the Session Bean interface defines ejbRemove, ejbPassivate (stored to secondary storage), and ejbActivate (restored from passive state). You don't get to control when these methods are called, just what they do. The container calls us, we don't call it.
This leads to the difference between framework and library:
Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.
I think, the point of view that DI is IOC, means the dependency of an object is inverted: instead it controls its own dependencies, life cycle... something else does it for you. But, as you told me about DI by hands, DI is not necessarily IOC. We can still have DI and no IOC.
However, in this paper (from the pococapsule, another IOC Framework for C/C++), it suggests that because of IOC and DI, the IOC containers and DI frameworks are far more superior to J2EE, since J2EE mixes the framework code into the components, thus not making it Plain Old Java/C++ Object (POJO/POCO).
Inversion of Control Containers other than the Dependency Injection pattern : http://www.pocomatic.com/docs/whitepapers/ioc-vs-di/
Additional reading to understand what's the problem with old Component-Based Development Framework, which leads to the second paper above: Why and what of Inversion of Control : http://www.pocomatic.com/docs/whitepapers/ioc/
My Question : What's exactly is IOC and DI? I am confused. Based on pococapsule, IOC is something more significant than just invert the control of objects or between programmers and frameworks.
IoC is a generic term meaning rather than having the application, call the methods in a framework, the framework calls implementations provided by the application.
DI is a form of IoC, where implementations are passed into an object through constructors/setters/service lookups, which the object will 'depend' on in order to behave correctly.
IoC without using DI , for example would be the Template pattern because the implementation can only be changed through sub-classing.
DI Frameworks are designed to make use of DI and can define interfaces (or Annotations in Java) to make it easy to pass in the implementations.
IoC Containers are DI frameworks that can work outside of the programming language. In some you can configure which implementations to use in metadata files (eg XML) which are less invasive. With some you can do IoC that would normally be impossible like inject an implementation at pointcuts.
See also this Martin Fowler's article.
In short, IoC is a much broader term that includes, but is not limited to, DI
The term Inversion of Control (IoC) originally meant any sort of programming style where an overall framework or run-time controlled the program flow
Before DI had a name, people started to refer to frameworks that manage Dependencies as Inversion of Control Containers, and soon, the meaning of IoC gradually drifted towards that particular meaning: Inversion of Control over Dependencies.
Inversion of Control (IoC) means that objects do not create other objects on which they rely to do their work. Instead, they get the objects that they need from an outside source (for example, an xml configuration file).
Dependency Injection (DI) means that this is done without the object intervention, usually by a framework component that passes constructor parameters and set properties.
DI is a subset of IoC
Here are some other techniques to achieve IoC.
链接地址: http://www.djcxy.com/p/2324.html上一篇: 为什么要使用依赖注入？
下一篇: 控制反转与依赖注入