IoC/DI基本思想的演变

----------------------------------------------------------------------------------

(1)IoC/DI的概念

　IoC --- Inversion of Control,控制反转

　　在Java开发中,IoC意味着将你设计好的类交给系统去控制，而不是在类的内部控制。IoC是一种让服务消费者不直接依赖于服务提供者的组件设计方式，是一种减少类与类之间依赖的设计原则。

　DI -- Dependency Injection(依赖注入)
　　即组件之间的依赖关系由容器在运行期决定，形象的来说，即由容器动态的将某种依赖关系注入到组件之中去。
　　依赖注入的目标并非为软件系统带来更多的功能，而是为了提升组件重用的概率，并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制，我们只需要通过简单的配置，而不需任何代码就可以指定目标需要的资源，完成自身的业务逻辑，而不用关心具体的资源来自何处，由谁实现。

(2)IoC/DI基本思想的演变

　　第一个阶段:(Java基本阶段)

　　　　有一个接口A和两个实现类A1、A1.

　　　　

　　如果类B想要使用类A1或者类A2的话，基本的写法如下:

 　　public class B{

 　　　　public void test(){

 　　　　　　A a = new A1();

 　　　　　　a.method1();

 　　　　}
 　　}

　　上面的代码中，对于B类来说是主动实例化对象，直接获取依赖，这种实现方式的缺点： 更换实现类需要重新编译源代码、耦合了实例生产者和实例消费者。

　　第二个阶段:(Factory+XML)

　　

　　在第二个阶段中使用了工厂模式--Factory,在B类中需要使用接口A,直接去工厂里面获取:

　　　　A a = Factory.createA();

　　然后拿到a的实现后就可以调用接口的方法，这样对于B类来说是被动实例化对象，间接获取依赖，但是对于工厂类来说就是主动的，这种实现方式的缺点: 更换实现同样需要重新编译源代码。

　　第三个阶段:(Factory+XML+反射)

　　这个阶段是使用工厂模式+配置文件+反射，在B类里面需要使用接口A,应用工厂模式去获取：A a = Factory.createA(),然后通过a来调用接口方法。

　 在工厂类里使用配置文件来决定要实例化的具体类，对于B类来说是被动创建对象,间接获取依赖;对于工厂来说也是被动创建对象.这种实现方式的缺点: 如何实例化带参数的类、如何在调用方法时传递值。

　　第四个阶段:(IoC/DI)　　

　　

　　这个阶段是IoC/DI阶段了，出现了IoC/DI容器，此时每个类想要获取什么外部资源 都可以直接去找IoC/DI容器，由IoC/DI容器来提供。

　　此时由容器来创建对象和装配对象，并管理对象生命周期，对于应用程序而言，就是被动实例化和被动接受依赖了。　

(3)IoC/DI的基本思想

　　a.把程序之间的依赖关系去掉

　　b.把程序对象设置到IoC/DI容器的配置中，作为Bean

　　c.由IoC/DI容器来管理Bean的创建、实例化

　　d.由IoC/DI容器来把Bean之间的关系注入到需要这些关系的对象里面

　　简而言之：就是对象之间的依赖关系全部去掉，然后由IoC/DI容器来管理对象和对象之间的依赖关系。这样的好处：实现了对象之间的松散耦合