ioc浅析

个人主页

全称：Interface Driven Design接口驱动。

控制反转（Inverse of Control）

控制反转即IoC(Incersion of Control),从字面上理解就是控制反转，将对在自身对象中的一个内置对象的控制权反转。所谓的反转，即把内置对象的控制权反转给一个容器，而应用程序只需要提供对象的类型即可。

这是一种解耦的设计思想，并不是什么具体的技术。基本思想是:借助于“第三方”实现具有依赖关系的对象之间的解耦。实现IOC的技术手段：DI（依赖注入）和 DL（依赖查找），Spring中的核心机制就是DI（依赖注入）。通俗来说就是ServiceImpl类中，有Dao 对象，那就是ServiceImpl依赖了Dao。

依赖注入（Depedency Injection）

意思是自身对象中的内置对象是通过注入的方式进行创建。依赖注入有两种实现方式：Setter方式(传值方式)和构造器方式(引用方式)。

容器全权负责组件的装配，它会把符合依赖关系的对象通过属性（JavaBean中的setter）或者是构造子传递给需要的对象。

相对于IoC而言，依赖注入(DI)更加准确地描述了IoC的设计理念。所谓依赖注入，即组件之间的依赖关系由容器在应用系统运行期来决定，也就是由容器动态地将某种依赖关系的目标对象实例注入到应用系统中的各个关联的组件之中。

依赖查找（Dependency Lookup）

谷歌中还有个资料表明：依赖查找也有两种类型:依赖拖拽（DP）和上下文化依赖查找(CDL)。

IOC也就是控制反转，把对象的创建、初始化、销毁等工作都交给Spring容器。由spring容器来控制对象的生命周期。

Spring对象初始化bean时机：

在默认情况下，只要在Spring容器中配置了一个bean，容器在启动时就会实例化该bean，单例模式。
如果在Spring配制文件时设置懒加载模式（lazy-init=”true”），在getBean时才会实例化对象。
如果scope=”prototype”时，无论lazy-init的值是什么都只会在使用时才会创建。

Spring容器生命周期：

单例

<bean id="accountService" class="com.luban.service.impl.AccountServiceImpl"
scope="singletion" init-method="init" destroy-method="destroy"></bean>

多例

<bean id="accountService" class="com.luban.service.impl.AccountServiceImpl"
  scope="prototype" init-method="init" destroy-method="destroy"></bean>

为什么要用IOC？

第一：对象的实例化不是一件简单的事情，比如对象的关系比较复杂，依赖关系往往需要程序员去维护，这是一件非常头疼的事。

第二：解耦，由容器去维护具体的对象

第三：托管了类的产生过程，比如我们需要在类的产生过程中做一些处理，最直接的例子就是代理，如果有容器程序可以把这部分过程交给容器，应用程序则无需去关心类是如何完成代理的

作用

第一，资源集中管理，实现资源的可配置和易管理。

第二，降低了使用资源双方的依赖程度，也就是我们说的耦合度。

看到的一个特别通俗的例子：

也就是说，甲方要达成某种目的不需要直接依赖乙方，它只需要达到的目的告诉第三方机构就可以了，比如甲方需要一双袜子，而乙方它卖一双袜子，它要把袜子卖出去，并不需要自己去直接找到一个卖家来完成袜子的卖出。它也只需要找第三方，告诉别人我要卖一双袜子。这下好了，甲乙双方进行交易活动，都不需要自己直接去找卖家，相当于程序内部开放接口，卖家由第三方作为参数传入。甲乙互相不依赖，而且只有在进行交易活动的时候，甲才和乙产生联系。反之亦然。这样做什么好处么呢，甲乙可以在对方不真实存在的情况下独立存在，而且保证不交易时候无联系，想交易的时候可以很容易的产生联系。甲乙交易活动不需要双方见面，避免了双方的互不信任造成交易失败的问题。因为交易由第三方来负责联系，而且甲乙都认为第三方可靠。那么交易就能很可靠很灵活的产生和进行了。

这就是ioc的核心思想。生活中这种例子比比皆是，支付宝在整个淘宝体系里就是庞大的ioc容器，交易双方之外的第三方，提供可靠性可依赖可灵活变更交易方的资源管理中心。另外人事代理也是，雇佣机构和个人之外的第三方。