控制反转 IOC 与依赖注入 DI

引言

简单总结和巩固一下spring的核心原理——IOC和DI的概念，为什么IOC要叫控制反转？IOC和DI的关系是怎样的？

一、IOC 控制反转

初学者可能很好奇，为什么spring framework的对象托管容器叫做 IOC容器（Inversion of control）？

设想这样一个场景，A对象依赖B对象。如果 new A，就需要先 new B，这是最基本的依赖创建方式。我们管 A 去申请 B 对象的过程，称为“资源查找”，可以理解为 A 对象需要向虚拟机申请一个资源 B 对象。

传统的资源查找（如上所述）要求组件向容器（可以理解为JVM）主动发起请求，查找资源作为响应，容器适时返回资源。

这种方式要求每个 Java 对象必须自己控制实例化的过程。存在的问题就是，当依赖对象过多，层层依赖等情况，创建对象的过程将会极其复杂和冗长，极大地降低了代码的维护性和健壮性。

IOC资源查找方式是容器根据配置文件的描述统一管理组件的构造和依赖，主动注入依赖。对象创建的控制权由传统方式的对象主动发起资源申请，变为对象被动接收依赖注入。因此得名 Inversion of control 控制反转。

IOC是一种更侧重于原理的技术描述，它描述了一种被动依赖注入的对象托管服务理念。

二、DI 依赖注入

Dependency Injection 依赖注入，是比 IOC 更广泛的概念，它包含 IOC ，因此 IOC 有时候也称为 DI 。

任何情况的对象组装都可以称为依赖注入，如前面提到的创建 A 时，通过构造器或属性赋值传入 对象 B，这就是依赖注入的含义。

显而易见，由前面提到的“传统资源查找”的对象创建方式属于“主动依赖注入”，而 IOC 就属于被动依赖注入。

不过随着被动依赖注入的理念深入人心，IOC 与 DI 的概念经常一并提起，因此有时候二者也会混用，但实际上 DI 是包含 IOC 的。

DI 可以理解为 IOC 的另一种表达方式，即组件以一些预先定义好的方式（如 setter）接收来自容器的资源注入。相比于IOC 而言，这种表达方式更加直观易懂。