springIOC容器（一）

IOC容器

译为：控制反转 亦或 依赖注入
著名的好莱坞原则“Don’t call us, we will call you”恰当的表达了”反转”的意味

带着疑问：

1. 为什么需要IoC？
2. IoC的具体意义是什么？
3. 它到底有什么独到之处？

引入IOC

传统的对象初始化方式，需要自己手动获取对象依赖的其他对象，每次用到什么依赖对象都要主动地去获取。这种方式是否有必要？
思考：只要用到这个依赖对象的时候，它能够准备就绪，我们完全可以不管这个对象是自己找来的还是别人送过来的。

IOC提供了更加轻松简洁的方式。它的反转，就反转在让你从原来的事必躬亲，转变为现在的享受服务。IOC的理念就是，让别人为你服务。

现在来看 被注入对象和被依赖对象之间的关系：
1. 源码期，被注入对象不需要知道依赖对象具体的实现以及初始化问题
2. 两者没有直接的关联，通过IOC容器完成注入服务与传统的直接获取依赖对象的方式，通过IOC容器注入，依赖对象的获取方式发生了反转控制对象的注入时机也从被注入对象转移到IOC容器中

前后差别如图：

使用IOC

作为被注入的对象，想要IOC容器提供服务，将所需要的依赖对象注入进来，也必定要以某种方式通知IOC容器来表达自己的需求：
1. 构造方法注入：顾名思义，构造方法注入，就是被注入对象可以通过在其构造方法中声明依赖对象的参数列表，让外部（通常是IoC容器）知道它需要哪些依赖对象

    取得它所需要的依赖对象列表
    进而为其注入相应的对象
    同一个对象是不可能被构造两次的
    容器管理被注入对象的整个生命周期

2. setter方法注入：javaBean规范，每个字段需要对应的getter setter方法名为访问器和设置器，可以通过setter方法将相应的依赖对象设置到被注入对象中

    setter方法注入不同于构造方法注入
    对象构造完成后不能即可使用

3. 接口注入（使用较少）：相对于前两种注入方式来说，接口注入没有那么简单明了。被注入对象如果想要IoC Service Provider为其注入依赖对象，就必须实现某个接口。

    接口提供一个方法，用来为其注入依赖对象
    注入比较死板和烦琐

4. 注解注入：spring2.5后 支持jdk1.5引入的注解特性，在字段上使用@Autowired(根据类型注入)，或者@Resource(先在容器中根据字段名寻找对应id的bean注入，否则根据类型注入)

比较前三种注入方式：
接口注入。从注入方式的使用上来说，接口注入是现在不甚提倡的一种方式，基本处于“退役状态”。因为它强制被注入对象实现不必要的接口，带有侵入性。而构造方法注入和setter方法注入则不需要如此。

构造方法注入。 这种注入方式的优点就是，对象在构造完成之后，即已进入就绪状态，可以马上使用。缺点就是，当依赖对象比较多的时候，构造方法的参数列表会比较长。而通过反射构造对象的时候，对相同类型的参数的处理会比较困难，维护和使用上也比较麻烦。而且在Java中，构造方法无法被继承，无法设置默认值。对于非必须的依赖处理，可能需要引入多个构造方法，而参数数量的变动可能造成维护上的不便。

setter方法注入。因为方法可以命名， 所以setter方法注入在描述性上要比构造方法注入好一些。另外， setter方法可以被继承，允许设置默认值，而且有良好的IDE支持。缺点当然就是对象无法在构造完成后马上进入就绪状态。

从主动获取依赖关系的方式转向IoC方式，不只是一个方向上的改变，简单的转变背后实际上蕴
藏着更多的玄机
IOC普遍认识的优势：非侵入性，可测试性，可重用性，可扩展性等。
IOC是一种可以帮助我们解耦各业务对象间依赖关系的对象绑定方式