IOC控制反转

全名：Inversion of Control

传统的开发模式：对象之间互相依赖。当对象A创建的时候，由于其与B和C相依赖，因此A将会主动创建B和C，无论是创建还是使用B和C，控制权都在A手上

ord.png

ioc开发模式：IOC容器安排对象之间的依赖。此时，引入IOC容器，对象A和B、C失去了直接联系，当对象A需要使用B（C）的时候，IOC容器会自动注入（DI——依赖注入）一个对象B（C）到A所需要的地方，如此，对象A获取对象B的主动行为变成了被动行为，控制权颠倒了过来。

ioc.png

最终的解耦合：我们希望的结果

res.png

在以上，A获得与使用依赖对象B的过程由A主动创建使用变为了由IOC容器主动注入，事实上，IOC的控制反转指的是获得依赖对象的过程被反转了，也因此，IOC有了另外一个名字——DI（依赖注入）。

DI：即IOC容器在运行时期，动态地将某种依赖关系注入到对象中；实际上，DI讲的是IOC的实现方法——注入

IOC和DI其实是站在两个角度描述同一件事——引入IOC容器，实现关系解耦合。

借用网上通用的例子：

利用电脑主机和USB接口来实现一个任务：从外部USB设备读取一个文件。

电脑主机读取文件的时候，它并不关心USB接口上连接的是什么外部设备，它的任务是读取符合USB接口标准的外设。所以，如果我给电脑主机连接上一个U盘，那么主机就从U盘上读取文件；如果我给电脑主机连接上一个外置硬盘，那么电脑主机就从外置硬盘上读取文件。挂接外部设备的权力由我作主，即控制权归我，至于USB接口挂接的是什么设备，电脑主机是决定不了，它只能被动的接受。电脑主机需要外部设备的时候，根本不用它告诉我，我就会主动帮它挂上它想要的外部设备，你看我的服务是多么的到位。这就是我们生活中常见的一个依赖注入的例子。在这个过程中，我就起到了IOC容器的作用。

这个例子中，依赖注入的思路非常清楚：当电脑主机读取文件的时候，我就把它所要依赖的外部设备，帮他挂接上。整个外部设备注入的过程和一个被依赖的对象在系统运行时被注入另外一个对象内部的过程完全一样。更有，IOC就像一个工厂，要啥给啥（当然需要合理的要求），不用了也会自动销毁。传统的实现中，常由new关键字实现两个关系之间的组合，带来组件间的高耦合性。

IOC的好处：

1. USB作为电脑外设，双方无论哪一者出现问题，都不会影响另外一方运行，可维护性好，便于单元测试，组件之间低耦合
2. （其实也是低耦合带来的好处）USB厂商和电脑厂商是不相干的人，各干其事，只要遵守USB接口标准即可。放到团队中，对内成员分工明确，自己的任务不依赖于别人的组件。
3. （还是低耦合的好处）模块复用性好，同一个USB可以插入任何支持此标准的设备
4. IOC生成对象的方式是外置方式，也就是把对象生成放到配置文件里进行定义

IOC技术内剖：

IOC中最基本的技术就是“反射(Reflection)”编程(反射：通俗来讲就是根据给出的类名（字符串方式）来动态地生成对象)，这种编程方式可以让对象在生成时才决定到底是哪一种对象。

可以把IOC看成是升华的工厂模式，这个工厂里要生产的对象都在配置文件中给出定义，然后利用编程语言的的反射编程，根据配置文件中给出的类名生成相应的对象。由配置文件确定要生成的对象，而工厂负责生成对象，也就是把工厂和对象生成这两者独立分隔开来，提高灵活性和可维护性。

使用IOC框架注意：

1. 学习成本——团队中成员都应该懂
2. 反射机制会降低运行效率
3. 大量配置工作

对于工作量不大的项目、强调效率、队伍成员知识欠缺者，慎用。

参考：

http://blog.csdn.net/icarus_wang/article/details/51457866
http://blog.csdn.net/wanghao72214/article/details/3969594

稍触皮毛，有误zhe请指教。