Java - Spring框架：理解 IOC

1 什么是 IOC

IOC（Inversion of Control，控制反转）是一种计算机程序设计原则。百度百科中对控制反转有以下说明：IOC 设计原则的目的是用于降低代码之间的耦合度，其中最常见的 IOC 实现方式叫做 DI（Dependency Injection，依赖注入）。

以 IOC 的方式创建一个对象的过程可以被描述为：通过一个调控系统生成一个该对象的实体，并将该对象实体在创建或使用时所依赖的其它对象的引用传递给它，也就是将依赖注入到对象。在基于 Java 语言的后端开发技术栈中，上文提到的调控系统的一种具体实现就是 Spring 框架。而这些对象及其依赖的承载实体在 Spring 框架中被称为容器。

IOC 意味着将开发者设计好的对象转交给 Spring 容器来控制，而非在开发代码的过程中控制依赖对象的实例化。理解 IOC 设计原则，关键是要明确 “谁控制谁？控制什么？何谓反转？何处反转？”

1.1 谁控制谁，控制什么

对于传统 Java SE 程序设计，我们直接在对象内部通过 new 关键字完成对象创建，是程序主动去创建依赖对象，主导权在开发者；而在基于 IOC 思想的程序设计中，则会有专门的容器来创建这些依赖对象，即由 IOC 容器来控制对象的创建。显然：

• 谁控制谁：IOC 容器控制了对象的创建及其整个生命周期内的活动；
• 控制什么：控制了外部资源获取（不只是对象，还包括比如文件等其它资源）。

1.2 何谓反转，何处反转

理解反转，首先要明晰 “正转”：在非 IOC 设计思想的程序开发中，依赖对象的获取和实例化由开发者自行决定。也就是正向控制对依赖的获取和使用。在 IOC 设计思想中：

• 何谓反转：依赖对象的控制权由开发者变为 IOC 容器，也就是由 IOC 容器反向控制对象依赖的创建（注入），目标对象只是被动地接受 IOC 容器注入。
• 何处反转：反转体现在依赖对象的创建过程中。

传统应用程序示意图（a）与有IOC/DI容器后程序结构示意图（b）

1.3 IOC 与 “依赖注入”

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

• 谁依赖谁：应用程序依赖于 IOC 容器；
• 为何依赖：应用程序需要 IOC 容器来提供对象需要的外部资源；
• 谁注入谁：IOC 容器根据依赖配置将对应的依赖内容注入到目标对象中；
• 注入什么：就是注入目标对象所需要的外部资源（包括对象、外部资源、常量数据等）。

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

2 IOC 思想的主旨

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

其实 IOC 对编程带来的最大改变不是从代码上，而是从思想上，发生了 “主从换位” 的变化。应用程序原本是老大，要获取什么资源都是主动出击。但是在 IOC/DI 思想中，应用程序称为被动一方来等待 IOC 容器来创建并注入它所需要的资源。也就是由 IOC 容器帮对象找相应的依赖对象并注入，而不是由对象主动去找。

3 参考资料

1. https://www.iteye.com/blog/jinnianshilongnian-1413846
2. https://www.cnblogs.com/xdp-gacl/p/4249939.html
3. https://www.cnblogs.com/chenssy/p/9576769.html