控制反转&依赖注入DI

1.(通俗的解释)
Spring 中的技术,有别于一般的设计实现方式.
控制反转（IoC = Inversion of Control）
IoC，用白话来讲，就是由容器控制程序之间的关系，而非传统实现中，由程序代码直接操控。这也就是所谓“控制反转”的概念所在：控制权由应用代码中转到了外部容器，控制权的转移，是所谓反转。
USB接口例子：
笔记本电脑与外围存储设备通过预先指定的一个接口（USB）相连，对于笔记本而言，只是将用户指定的数据发送到USB接口，而这些数据何去何从，则由当前接入的USB设备决定。在USB 设备加载之前，笔记本不可能预料用户将在USB接口上接入何种设备，只有USB设备接入之后，这种设备之间的依赖关系才开始形成。
对应上面关于依赖注入机制的描述，在运行时（系统开机，USB 设备加载）由容器（运行在笔记本中的Windows操作系统）将依赖关系（笔记本依赖USB设备进行数据存取）注入到组件中（Windows文件访问组件）。
理解：
传统模式中是类和类之间直接调用，所以有很强的耦合度，程序之间的依赖关系比较强，后期维护时牵扯的比较多。
IOC，用配置文件(XML)来描述类与类之间的关系，由容器来管理，降低了程序间的耦合度，程序的修改可以通过简单的配置文件修改来实现。

2.(专业的解释)
控制反转（Ioc）模式(又称DI：Dependency Injection)就是Inversion of Control，控制反转。在Java开发中，IoC意味着将你设计好的类交给系统去控制，而不是在你的类内部控制。这称为控制反转。

IoC(Inversion of Control)是近年来兴起的一种思想，不仅仅是编程思想。主要是协调各组件间相互的依赖关系，同时大大提高了组件的可移植性，组件的重用机会也变得更多。在传统的实现中，由程序内部代码来控制程序之间的关系。我们经常使用new关键字来实现两组键间关系的组合，这种实现的方式会造成组件之间耦合(一个好的设计，不但要实现代码重用，还要将组件间关系解耦)。IoC很好的解决了该问题，它将实现组件间关系从程序内部提到外部容器来管理。也就是说由容器在运行期将组件间的某种依赖关系动态的注入组件中。控制程序间关系的实现交给了外部的容器来完成。即常说的好莱坞原则“Don't call us,we'll call you”。

Ioc也有称为DI(Dependecy Injection 依赖注射)，由Martin Fowler的一篇《Inversion ofControl Containers and the Dependency Injection pattern》提出。
　　分离关注（ Separation of Concerns : SOC）是Ioc模式和AOP产生最原始动力，通过功能分解可得到关注点，这些关注可以是组件Components,方面Aspects或服务Services。

　　从GoF设计模式中，我们已经习惯一种思维编程方式：Interface Driven Design 接口驱动，接口驱动有很多好处，可以提供不同灵活的子类实现，增加代码稳定和健壮性等等，但是接口一定是需要实现的，也就是如下语句迟早要执行：

　　AInterface a = new AInterfaceImp();

　　AInterfaceImp是接口AInterface的一个子类，Ioc模式可以延缓接口的实现，根据需要实现，有个比喻：接口如同空的模型套，在必要时，需要向模型套注射石膏，这样才能成为一个模型实体，因此，我们将人为控制接口的实现成为“注射”。

　　Ioc英文为 Inversion of Control，即反转模式，这里有著名的好莱坞理论：你呆着别动，到时我会找你。

　　其实Ioc模式也是解决调用者和被调用者之间的一种关系，上述AInterface实现语句表明当前是在调用被调用者AInterfaceImp，由于被调用者名称写入了调用者的代码中，这产生了一个接口实现的原罪：彼此联系，调用者和被调用者有紧密联系，在UML中是用依赖 Dependency 表示。

　　但是这种依赖在分离关注的思维下是不可忍耐的，必须切割，实现调用者和被调用者解耦，新的Ioc模式 Dependency Injection 模式由此产生了， Dependency Injection模式是依赖注射的意思，也就是将依赖先剥离，然后在适当时候再注射进入。

一、Ioc模式（Dependency Injection模式）有三种：

第一种类型从JNDI或ServiceManager等获得被调用者，这里类似ServiceLocator模式。 1. EJB/J2EE，2. Avalon（Apache的一个复杂使用不多的项目）
第二种类型 使用JavaBeans的setter方法 1. Spring Framework,2. WebWork/XWork
第三种类型 在构造方法中实现依赖 1. PicoContainer,2. HiveMind

　　有过EJB开发经验的人都知道，每个EJB的调用都需要通过JNDI寻找到工厂性质的Home接口，在我的教程EJB是什么章节中，我也是从依赖和工厂模式角度来阐述EJB的使用。

　　在通常传统情况下，为了实现调用者和被调用者解耦，分离，一般是通过工厂模式实现的，下面将通过比较工厂模式和Ioc模式不同，加深理解Ioc模式。

二、工厂模式和Ioc

　　假设有两个类B 和 C：B作为调用者，C是被调用者，在B代码中存在对C的调用：

public class B{
　　 private C comp;
　　......
}
　　实现comp实例有两种途径：单态工厂模式和Ioc。工厂模式实现如下：

public class B{
　　 private C comp;
　　private final static MyFactory myFactory = MyFactory.getInstance();

　　public B(){
　　　　this.comp = myFactory.createInstanceOfC();

　　}
　　 public void someMethod(){
　　　　this.comp.sayHello();
　 }
　　......
}
特点：

每次运行时，MyFactory可根据配置文件XML中定义的C子类实现，通过createInstanceOfC()生成C的具体

实例。
使用Ioc依赖性注射( Dependency Injection )实现Picocontainer如下，B类如同通常POJO类，如下：

public class B{
　　 private C comp;
　　public B(C comp){
　　　　this.comp = comp;
　　 }
　　 public void someMethod(){
　　　　this.comp.sayHello();
　　 }
　　......
}
假设C接口/类有有一个具体实现CImp类。当客户端调用B时，使用下列代码：

public class client{
　　 public static void main( String[] args ) {
　　　　DefaultPicoContainer container = new DefaultPicoContainer();
　　　　container.registerComponentImplementation(CImp.class);
　　　　container.registerComponentImplementation(B.class);
　　　　B b = (B) container.getComponentInstance(B.class);
　　　　b.someMethod();
　　 }
}
　　因此，当客户端调用B时，分别使用工厂模式和Ioc有不同的特点和区别：

　　主要区别体现在B类的代码，如果使用Ioc，在B类代码中将不需要嵌入任何工厂模式等的代码，因为这些工厂模式其实还是与C有些间接的联系，这样，使用Ioc彻底解耦了B和C之间的联系。

　　使用Ioc带来的代价是：需要在客户端或其它某处进行B和C之间联系的组装。

　　所以，Ioc并没有消除B和C之间这样的联系，只是转移了这种联系。
　　这种联系转移实际也是一种分离关注，它的影响巨大，它提供了AOP实现的可能。

Ioc和AOP
　　AOP我们已经知道是一种面向切面的编程方式，由于Ioc解放自由了B类，而且可以向B类实现注射C类具体实现，如果把B类想像成运行时的横向动作，无疑注入C类子类就是AOP中的一种Advice。

　　通过下列代码说明如何使用Picocontainer实现AOP，该例程主要实现是记录logger功能，通过Picocontainer可以使用简单一行，使所有的应用类的记录功能激活。首先编制一个记录接口：

public interface Logging {

　　public void enableLogging(Log log);

}
有一个LogSwitcher类，主要用来激活具体应用中的记录功能：

import org.apache.commons.logging.Log;
public class LogSwitcher
{
　 protected Log m_log;
　 public void enableLogging(Log log) {
　　　　m_log = log;
　　　　m_log.info("Logging Enabled");
　　}
}

一般的普通应用JavaBeans都可以继承这个类，假设PicoUserManager是一个用户管理类，代码如下：

public class PicoUserManager extends LogSwitcher
{
　　..... //用户管理功能
}
public class PicoXXXX1Manager extends LogSwitcher
{

　　..... //业务功能
}
public class PicoXXXX2Manager extends LogSwitcher
{

　　..... //业务功能
}
注意LogSwitcher中Log实例是由外界赋予的，也就是说即将被外界注射进入，下面看看使用Picocontainer是如何注射Log的具体实例的。

DefaultPicoContainer container = new DefaultPicoContainer();
container.registerComponentImplementation(PicoUserManager.class);
container.registerComponentImplementation(PicoXXXX1Manager.class);
container.registerComponentImplementation(PicoXXXX2Manager.class);
.....

Logging logging = (Logging) container.getComponentMulticaster();

logging.enableLogging(new SimpleLog("pico"));//激活log

　　由上代码可见，通过使用简单一行logging.enableLogging()方法使所有的应用类的记录功能激活。这是不是类似AOP的advice实现？

　　总之，使用Ioc模式，可以不管将来具体实现，完全在一个抽象层次进行描述和技术架构，因此，Ioc模式可以为容器、框架之类的软件实现提供了具体的实现手段，属于架构技术中一种重要的模式应用。J道的JdonSD框架也使用了Ioc模式。

参考资料：

Inversion of Control Containers and the Dependency Injection pattern
A Brief Introduction to IoC
Ioc容器的革命性优点
Java企业系统架构选择考量
IOC模式的思考和疑问

三、IoC的几种实现类型

(1)Type1接口注入

通常做法是利用接口将调用者与实现者分离。
public class Sport {
private InterfaceBall ball; //InterfaceBall是定义的接口
public void init() {
//Basketball实现了InterfaceBall接口
ball = (InterfaceBall) Class.forName("Basketball").newInstance();
}
}
Sport类在编译期依赖于InterfaceBall的实现，为了将调用者与实现者分离，我们动态生成Basketball类并通了强制类型转换为InterfaceBall。Apache Avalon是一个典型的Type1型IoC容器。

(2)setter方法注入

在类中暴露setter方法来实现依赖关系。
public class Sport {
private InterfaceBall ball;
public void setBall(InterfaceBall arg) {
ball = arg;
}
}
这种方式对已经习惯了JavaBean的程序员而言，更显直观。Spring就是实现了该类型的轻量级容器。

(3)Type3构造子注入

即通过构造方法完成依赖关系。 public class Sport { private InterfaceBall ball; public Sport(InterfaceBall arg) { ball = arg; } } 可以看到，通过类的构造方法建立依赖关系。由于Type3在构造期就形成了对象的依赖关系，即存对象的重用变的困难。有些框架需要组件提供一个默认的构造方法，此时就体现了Type3的局限性。通常所有的参数都是通过构造方法注入的，当对象间的依赖关系较多时，构造方法就显的比较复杂，不利于单元测试。PicoContainer就是实现了Type3依赖注入模式的轻量级容器。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!