Java：Spring的IOC原理（大白话解释）

先行参考以下半成品文章和参考链接，待学完课程后续整理此文章

IOC和DI关系

IOC：Inversion of Control，控制反转
DI：Dependency Injection，依赖注入
关系：IOC是一种面向编程设计思想，DI是IOC思想的实现方式，即：DI实现IOC这一思想

Q&A

那么问题来了：IOC是一种什么思想？DI实现的什么？
IOC思想：借助“第三方”，实现具有依赖关系的对象间解耦合

• 第三方的理解：Spring框架中的IOC容器
• 实现的理解：通过引入IOC容器，利用依赖关系注入的方式创建对象（依赖注入可理解为：通过某种依赖关系，创建对象），实现对象之间的解耦
• 对象的理解：
  • 广义上讲：对象、模块、软件系统或硬件系统
  • 狭义上讲：new 出的对象

那么问题又来了：何为耦合？
耦合：对象间的依赖关系，如下：

一个齿轮系统中，各齿轮可看做一个对象，要想此系统运动起来，各齿轮间必须协作运行，这种协作运行的状态可以成为一种耦合关系。但，耦合程度一旦过高，某个齿轮不运作，就容易导致整个齿轮系统崩溃，即：牵一发而动全身。同理，软件系统中也有此种问题存在。
为了解决软件系统中因耦合程度高，导致系统“牵一发而动全身”崩溃的问题，软件专家Michael Mattson提出了IOC理论，用来实现对象之间的“解耦”，目前这个理论已经被成功地应用到实践当中，很多的J2EE项目均采用了IOC框架产品Spring。
解耦合后的齿轮系统，如下：

IOC容器再理解

对后续参考链接：“2【死磕 Spring】----- IOC 之深入理解 Spring IoC”的理解

抽象理解IOC容器的作用：
在没有IOC容器时，对象A想要对象B，则对象A自己创建对象B
有IOC容器时，对象A想要对象B，IOC容器创建对象B，交给对象A，即：对象A只需提需求，IOC容器代劳完成需求

实例理解IOC容器（参考链接2）：
场景铺垫：小明和小翠那段不可告人的秘密…
版本1（未使用IOC）：那个阳光明媚的下午，小公园里，石桌前，阳光洒在小翠的书上，微风轻轻拂过她的脸颊…小明路过此地，此情此景此人，无不让人动情，随后小明便对小翠展开了“猛烈攻势”，在一番“跪舔”下，小明终究明白了一个道理：“我应该是一个好人！”，小翠也印证了那句话：“你喜欢我没用，因为我喜欢学习！”
版本1.5（使用IOC）：被小翠拒绝后的小明，“痛定思痛”，决定不再主动追求女生了，决定“两耳不闻窗外事，一心只读圣贤书”，女朋友就交给“婚介公司”吧！随后，小明在“婚介公司”登记了一下自己的信息，目标女生的要求（身高、体重、学历等），便不再主动寻求对象，而是通过婚介公司代为其寻找匹配…

上述不太有情调的例子中，对象A对应小明，对象B对应小翠，“婚介公司”对应IOC容器！

IOC 控制反转四问

如何理解“控制反转”好呢？理解好它的关键在于我们需要回答如下四个问题：

1. 谁控制谁？
2. 控制什么？
3. 为何是反转？
4. 哪些方面反转了？

现在在看上面那四个问题，答案就显得非常明显了:

1. 谁控制谁：在传统的开发模式下，我们都是采用直接 new 一个对象的方式来创建对象，也就是说你依赖的对象直接由你自己控制，但是有了 IOC 容器后，则直接由 IOC 容器来控制。所以“谁控制谁”，当然是 IOC 容器控制对象。
2. 控制什么：控制对象。
3. 为何是反转：没有 IOC 的时候我们都是在自己对象中（对象A：小明）主动去创建被依赖的对象（对象B：小翠），这是正转。但是有了 IOC （“婚介公司”）后，所依赖的对象（对象B：小翠）直接由 IOC 容器（“婚介公司”）创建后注入到被注入的对象中（对象A中：小明），依赖的对象（对象B：小翠）由原来的主动获取变成被动接受，所以是反转。
4. 哪些方面反转了：所依赖对象（对象B：小翠）的获取被反转了，即：主动获取反转为被动获取了。

“控制反转” 记忆句子：对象A主动获取对象B的方式；反转为对象B主动“送上门”对象A的方式，即：对象A获取对象B的方式由 主动反转为被动了（主动、被动以对象A的角度来说）

参考

1. Spring的IOC原理[通俗解释一下]
2. 【死磕 Spring】----- IOC 之深入理解 Spring IoC