IoC控制反转(即依赖注入模式DI)介绍

转自：http://www.nowamagic.net/program/program_AboutIoC.php

静态类的使用是一个有争议的话题，有人甚至提倡不要在类的名称上使用作用域限定符。关于静态特性争论的焦点在于一个被称为IoC控制反转的设计原则。

IoC这个设计原则试图在面向对象编程中去掉所有相互依赖的现象。这个原则对于复杂的系统来说是很重要的。它使得对象具有更好的多态性和封装性。相互依赖的现象越少，就越容易单独测试某个组件。

静态类与IoC之间的问题在于静态访问特性，这个特性从本质上来说，定义了两个类之间的绑定关系，因为类的名称是硬编码的。这就意味着在单独测试某个类的时候，这个类不容易被模拟。

就是说，静态类的使用会导致IoC设计原则受到限制。这是因为静态类的使用会导致类之间通过名称绑定在一起，这使得单独测试某个组件变得更加困难。

IoC的概念介绍

控制反转（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 of Control Containers and the Dependency Injection pattern》提出。

分离关注（Separation of Concerns : SOC）是Ioc模式和AOP产生最原始动力，通过功能分解可得到关注点，这些关注可以是组件Components，方面Aspects或服务Services。

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

1	AInterface a =  new   AInterfaceImp();

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

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

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

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

一个IoC的例子

假设我们要设计一个Girl和一个Boy类，其中Girl有kiss方法，即Girl想要Kiss一个Boy。那么，我们的问题是，Girl如何能够认识这个Boy？

在我们中国，常见的MM与GG的认识方式有以下几种：1、青梅竹马；2、亲友介绍；3、父母包办

那么哪一种才是最好呢？

青梅竹马：Girl从小就知道自己的Boy。

1	public   class   Girl {

2	void   kiss(){

3	Boy boy =  new   Boy();

4

}

5

}

然而从开始就创建的Boy缺点就是无法在更换。并且要负责Boy的整个生命周期。如果我们的Girl想要换一个怎么办？（笔者严重不支持Girl经常更换Boy）

亲友介绍：由中间人负责提供Boy来见面。

1	public   class   Girl {

2	void   kiss(){

3	Boy boy = BoyFactory.createBoy();

4

}

5

}

亲友介绍，固然是好。如果不满意，尽管另外换一个好了。但是，亲友BoyFactory经常是以Singleton的形式出现，不然就是，存在于Globals，无处不在，无处不能。实在是太繁琐了一点，不够灵活。我为什么一定要这个亲友掺和进来呢？为什么一定要付给她介绍费呢？万一最好的朋友爱上了我的男朋友呢？

父母包办：一切交给父母，自己不用费吹灰之力，只需要等着Kiss就好了。

1	public   class   Girl {

2	void   kiss(Boy boy){

3	// kiss boy

4	boy.kiss();

5

}

6

}

Well，这是对Girl最好的方法，只要想办法贿赂了Girl的父母，并把Boy交给他。那么我们就可以轻松的和Girl来Kiss了。看来几千年传统的父母之命还真是有用哦。至少Boy和Girl不用自己瞎忙乎了。

这就是IOC，将对象的创建和获取提取到外部。由外部容器提供需要的组件。