IOC&DI

IOC

IOC 反转控制 Inversion Of Control

面向对象设计的软件系统中，它的底层都是由N个对象构成的，各个对象之间通过相互合作，最终实现系统地业务逻辑。

齿轮啮(nie)合在一起协同工作，共同完成任务。但如果其中一个齿轮出现故障将会影响整个齿轮组的正常运转。

齿轮组中齿轮之间的啮合关系,与软件系统中对象之间的耦合关系非常相似。

IOC理论提出的观点大体是这样的：借助于“第三方”实现具有依赖关系的对象之间的解耦。

• 软件系统在没有引入IOC容器之前，对象A依赖于对象B，那么对象A在初始化或者运行到某一点的时候，自己必须主动去创建对象B或者使用已经创建的对象B。无论是创建还是使用对象B，控制权都在自己手上。
  

• 软件系统在引入IOC容器之后，这种情形就完全改变了，由于IOC容器的加入，对象A与对象B之间失去了直接联系，所以，当对象A运行到需要对象B的时候，IOC容器会主动创建一个对象B注入到对象A需要的地方。
  

对象A获得依赖对象B的过程,由主动行为变为了被动行为，控制权颠倒过来了，这就是“控制反转”这个名称的由来。

• 不使用IOC容器
  _{需要自己生产，创建对象，主动依赖}
  

• 使用IOC容器
  _{对象A运行到需要对象B的时候，IOC容器会主动创建一个对象B注入到对象A需要的地方}
  

DI

DI 依赖注入 Dependency Inject

2004年，Martin Fowler探讨了同一个问题，既然IOC是控制反转，那么到底是“哪些方面的控制被反转了呢？”，经过详细地分析和论证后，他得出了答案：“获得依赖对象的过程被反转了”。控制被反转之后，获得依赖对象的过程由自身管理变为了由IOC容器主动注入。于是，他给“控制反转”取了一个更合适的名字叫做“依赖注入（Dependency Injection）”。他的这个答案，实际上给出了实现IOC的方法：注入。所谓依赖注入，就是由IOC容器在运行期间，动态地将某种依赖关系注入到对象之中。

是指通过引入IOC容器，利用依赖关系注入的方式，实现对象之间的解耦。

控制被反转之后，获得依赖对象的过程由自身管理变为了由IOC容器主动注入

参考博文

• 浅谈IOC–说清楚IOC是什么-CSDN博客
• 理解 Spirng 中的 IoC 和 DI_哔哩哔哩_bilibili