理论场景化
在面向对象设计的软件系统中，它的底层都是由N个对象构成的，各个对象之间通过相互合作，最终实现系统地业务逻辑。
例：在机械表的内部，可以看到这样的情形。秒针的齿轮带动分钟的齿轮运转，分钟的齿轮带动时钟的齿轮运转，最终实现整个时间的展示。当然，如果其中一个齿轮出现了问题，那么其他齿轮系统也会出现问题，最终影响整个齿轮系统。
齿轮之间的联动关系，是不是与软件系统中对象之间的耦合关系非常相似。这些对象之间的耦合关系是无法避免的，也是必要的，这是协同工作的基础。
伴随着项目规模越来越大，对象之间的依赖关系也变的越来越复杂，常常出现对象之间的多重依赖关系。因此，程序员对于软件的设计，面临更大的挑战。对象之间耦合度过高的系统，会出现牵一发而动全身的现象。
耦合关系不仅会出现在对象与对象之间，也会出现在软件系统的各模块之间，以及软件系统和硬件系统之间。如何降低系统之间、模块之间和对象之间的耦合度，是软件工程永远追求的目标之一。
为了解决对象之间的耦合度过高的问题，软件专家Michael Mattson 1996年提出了IOC理论，用来实现对象之间的 “解耦”，目前这个理论已经被成功地应用到实践当中。
什么是IOC
IOC理论提出的观点大体是这样的：借助于“第三方IOC”实现具有依赖关系的对象之间的解耦
通过这张图，我们可以看到，原来一个 A、B、C、D 互相依赖的关系，没有了耦合关系。齿轮之间的传动，完全依赖于 IOC 。
我们再来做个试验：把上图中间的IOC容器拿掉，然后再来看看这套系统：
去掉 IOC 后可以发现， A、B、C、D 没有耦合关系。这样的话，在你实现A的时候，更本不需要去考虑 B、C、D 了。对象之间的依赖关系已经降低到了最低的程度。所以，如果真能实现IOC容器，对于系统开发而言，这将是一件多么美好的事情，参与开发的每一成员只要实现自己的类就可以了。
为什么叫控制反转(IOC)？
没有用IOC之前
对象A依赖于对象B，那么对象A在初始化或者运行到某一点的时候，自己必须主动去创建对象B或者使用已经创建的对象B。无论是创建还是使用对象B，控制权都在A自己手上。
用了IOC之后
由于IOC容器的加入，对象A与对象B之间失去了直接联系。当对象A运行到需要对象B的时候，IOC容器会主动创建一个对象B注入到对象A需要的地方。
总结：
对象A获得依赖对象B的过程,由主动行为变为了被动行为，控制权颠倒过来了，这就是“控制反转”这个名称的由来。
所谓依赖注入，就是由IOC容器在运行期间，动态地将某种依赖关系注入到对象之中。
Tips
IOC 也属于依赖注入（DI），不理解依赖注入概念的同学，请自行查阅资料学习。
软件案例剖析
传统程序设计都是主动去创建相关对象然后再组合起来如图，
当有了IoC/DI的容器后，在客户端类中不再主动去创建这些对象了，如图
