spring - ioc

业务场景

对象 X 需要这么多对象：A、B、C、D、E、F、G…… 你要怎么处理这种关系？

常规做法

你要先创建实例 X，然后再创建 A、B、C、D、E、F、G…… 最后一个个地 set。

问题

• 你 new 了这么多对象，是不是很容易就重复创建？（spring 容器解决的问题）
• 这么多的对象，是不是有可能少 set 几个了？（IOC 解决的问题）
• ………（等等）

分析 spring 的做法

我们把对象注册到 spring 容器，因为有一个注册的过程（@Service、@Component...），这样就解决了重复创建的问题。

每个对象需要引用什么对象，只需要列一个需求清单，也就是通过 @Resource 注解，声明你的需求，spring 根据需求，主动推送这个类，这样就解决了依赖注入的问题。

IOC

IOC 是 Inversion of Control 的缩写，翻译成 “控制反转”。

那么，哪些方面的控制被反转了呢？
获得依赖对象的过程被反转了，原先需要主动去获取对象的依赖，IOC 容器托管之后，对象的依赖由 IOC 容器主动注入。

因此，“控制反转” 有个一个更合适的名字叫做 “依赖注入（Dependency Injection）”，简写做 DI。

Martin Fowler 关于 IOC 和 DI 的文章（中文版）

这里引用一下别人文章的内容：Martin Fowler 关于 IOC 和 DI 的文章（中文版）

https://www.cnblogs.com/ChrisMurphy/p/5054429.html

Java社群近来掀起了一阵轻量级容器的热潮，这些容器能够帮助开发者将来自不同项目的组件组装成为一个内聚的应用程序。
在它们的背后有着同一个模式，这个模式决定了这些容器进行组件装配的方式。
人们用一个大而化之的名字来称呼这个模式：“控制反转”（ Inversion of Control，IoC）。
在本文中，我将深入探索这个模式的工作原理，给它一个更能描述其特点的名字——“依赖注入”（Dependency Injection）
，并将其与“服务定位器”（Service Locator）模式作一个比较。
不过，这两者之间的差异并不太重要，更重要的是：应该将组件的配置与使用分离开——两个模式的目标都是这个。