控制反转IOC

首先，不说定义。我们举个生动形象的例子来理解一下IOC和DI。
控制反转：
我们电脑上都有USB接口和HDMI接口等。电脑上用什么键盘不取决于电脑本身，而是插在USB上的键盘是什么。所以，控制电脑用什么输入的设备并不是由电脑控制的，而是由你插入的键盘是什么来控制的。这个控制不就反了么？
依赖注入：
电脑的输入设备依赖它被插入的是什么键盘。插入机械键盘，输入设备就是机械键盘；插入数字键盘，输入设备就是数字键盘。从插键盘这个事来说：无非事从电脑角度看，是依赖注入，输入什么设备依赖注入的键盘是什么；从键盘角度看就是控制反转，插入的键盘来控制电脑是什么输入设备。
依赖注入的目的就是可以灵活搭配。如果你的电脑上的键盘是焊死在电脑上的，键盘坏了，那么电脑也坏了。

IOC是什么

Ioc - Inversion of Control , 即"控制反转"。在开发中， IoC 意味着你设计好的对象交给容器控制，而不是使用传统的方式，在对象内部直接控制。

如何理解IOC

如何理解好 IoC 呢？理解好 IoC的关键是要明确"谁控制谁，控制什么，为何是反转(有反转就应该有正转)，哪些方面反转了"，我们来深入分析一下。

• 谁控制谁，控制什么：　在传统的程序设计中，我们直接在对象内部通过 new 的方式创建对象，是程序主动创建依赖对象；而 IoC 是有专门一个容器来创建这些对象，即由 IoC 容器控制对象的创建；谁控制谁？当然是 IoC 容器控制了对象；控制什么？主要是控制外部资源获取。
• 为何是反转了，哪些方面反转了：　有反转就有正转，传统应用程序是由我们自己在对象中主动控制去获取依赖对象，也就是正转；而反转则是由容器来帮忙创建及注入依赖对象；为何是反转？因为由容器帮我们查找及注入依赖对象，对象只是被动的接受依赖对象，所以是反转了；哪些方面反转了？依赖对象的获取被反转了。

IOC能做什么

Ioc 不是一种技术，只是一种思想，一个重要的面向对象编程法则，它能指导我们如何设计松耦合、更优良的系统。传统应用程序都是由我们在类内部主动创建依赖对象，从而导致类与类之间高耦合，难于测试；有了 IoC 容器后，把创建和查找依赖对象的控制权交给了容器，由容器注入组合对象，所以对象之间是松散耦合，这样也便于测试，利于功能复用，更重要的是使得程序的整个体系结构变得非常灵活。

其实 IoC 对编程带来的最大改变不是从代码上，而是思想上，发生了"主从换位"的变化。应用程序本来是老大，要获取什么资源都是主动出击，但在 IoC思想中，应用程序就变成被动了，被动的等待 IoC 容器来创建并注入它所需的资源了。

IOC和DI

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

理解 DI 的关键是：“谁依赖了谁，为什么需要依赖，谁注入了谁，注入了什么”，那我们来深入分析一下：　　
谁依赖了谁：当然是应用程序依赖 IoC 容器
为什么需要依赖：应用程序需要 IoC 容器来提供对象需要的外部资源
谁注入谁：很明显是 IoC 容器注入应用程序依赖的对象
注入了什么：注入某个对象所需的外部资源（包括对象、资源、常量数据）

---

IOC 和 DI 有什么关系？其实它们是同一个概念的不同角度描述，由于控制反转的概念比较含糊（可能只是理解为容器控制对象这一个层面，很难让人想到谁来维护依赖关系），所以 2004 年大师级人物 Martin Fowler 又给出了一个新的名字："依赖注入"，相对 IoC 而言，"依赖注入" 明确描述了被注入对象依赖 IoC 容器配置依赖对象。　

---

总的来说， 控制反转（Inversion of Control）是说创建对象的控制权发生转移，以前创建对象的主动权和创建时机由应用程序把控，而现在这种权利转交给 IoC 容器，它就是一个专门用来创建对象的工厂，你需要什么对象，它就给你什么对象。有了 IoC 容器，依赖关系就改变了，原先的依赖关系就没了，它们都依赖 IoC容器了，通过 IoC 容器来建立它们之间的关系。