Spring揭秘日志第一步：IOC基本概念

本篇文章是本人对本书中第二章的一些个人理解与整理的知识点。 众所周知，Spring始于IOC（Inversion of Control）控制反转，而它现在更多以依赖注入（DI）的方式被我们熟知。在这里还想到了一个设计原则——依赖倒转，下面先说明三者的关系。

Part1:控制反转、依赖注入与依赖倒转的关系

1、依赖倒转的相关概念

2、控制反转、依赖注入相关概念

(1)IOC：将对在自身对象中的一个内置对象的控制反转，反转后不再由自己本身的对象进行控制这个内置对象的创建，而是由第三方系统去控制这个内置对象的创建。 (2)DI（依赖注入）：全称为Dependency Injection，意思自身对象中的内置对象是通过注入的方式进行创建。 (3)这两者之间的具体关系为：IOC是一种设计思想、DI是该设计思想的一种具体体现。 3、依赖倒转 与 IOC、DI之间的关系：IOC与DI是依赖倒转的具体实现。（这里请注意一下依赖倒转原则中的依赖关系的传递方式，在说到IOC的三种注入方法时大家就会明白为啥是具体实现了。） Part2:IOC的理解 首先大家还是先看看IOC的图示理解几个场景： 在商店没有卖果汁之前，如果需要喝果汁，只能自己亲自买水果来自己榨汁，而出现了果汁商店后，要喝果汁只需要在前台中进行点单，由前台通知给后台做果汁的。果汁做好后通过前台递送给你。

在很早的时候，家里的家具只能自己打造，而有了家具商店后，你只需要说明自己的需求后，商店就会为你定制好，打造好后就会直接通知你来取。

这些场景都体现了IOC的一个很重要的思想：Don’t call us,we will call you.做事不需要亲自做，卫视委托第三方来完成。用到的依赖对象不一定要自己主动的去获取，而是享受IOC来为你提供服务。

Part3:依赖注入的方式

在对IOC提出你的请求时，必须要表达清楚你的意思，那么便会用到三种依赖注入方式：

1、构造方法注入：被注入对象可以通过在其构造方法中申明依赖对象的参数列表，让IOC容器知道它需要哪些依赖对象：下面是本书的代码实例。

public FXNewsProvider(IFXNewsListener newsListner,IFXNewsPersister newsPersister) { this.newsListener = newsListner; this.newPersistener = newsPersister; }

IoC Service Provider会检查被注入对象的构造方法，取得它所需要的依赖对象列表，进而为其注入相应的对象。同一个对象是不可能被构造两次的，因此，被注入对象的构造乃至其整个生命周期，应该是由IoC Service Provider来管理的。

2、setter方法注入：通过setter方法，可以更改相应的对象属性，所以当前对象只要为其依赖对象所对应的属性添加setter方法，就可以通过setter方法将相应的依赖对象设置到被注入对象中。以下是书中的示例代码。

Setter注入的特点（setter方法注入虽不像构造方法注入那样，让对象构造完成后即可使用，但相对来说更宽松一些，可以在对象构造完成后再注入。这就好比你可以到酒吧坐下后再决定要点什么啤酒，可以要百威，也可以要大雪，随意性比较强。如果你不急着喝，这种方式当然是最适合你的。）

1.public class FXNewsProvider 2.{ 3. private IFXNewsListener newsListener;//为依赖对象 4. private IFXNewsPersister newPersistener;//为依赖对象 5. 6. public IFXNewsListener getNewsListener() { 7. return newsListener; 8. } 9. public void setNewsListener(IFXNewsListener newsListener) { 10. this.newsListener = newsListener; 11. } 12. public IFXNewsPersister getNewPersistener() { 13. return newPersistener; 14. } 15. public void setNewPersistener(IFXNewsPersister newPersistener) { 16. this.newPersistener = newPersistener; 17. } 18.}

3、接口注入：被注入对象如果想要IoC Service Provider为其注入依赖对象，就必须实现某个接口。这个接口提供一个方法，用来为其注入依赖对象。IoC Service Provider最终通过这些接口来了解应该为被注入对象注入什么依赖对象。以下为UML图：

该方法的注入有些复制所以用文中比较让人容易理解的话来说：这就 好像你同样在酒吧点啤酒，为了让服务生理解你的意思，你就必须戴上一顶啤酒杯式的帽子看起来有点多此一举。

4、三种注入方式的比较：（该处为原文）

(1)接口注入：从注入方式的使用上来说，接口注入是现在不甚提倡的一种方式，基本处于“退役状态”。因为它强制被注入对象实现不必要的接口，带有侵入性。而构造方法注入和setter方法注入则不需要如此。 (2)构造方法注入：这种注入方式的优点就是，对象在构造完成之后，即已进入就绪状态，可以马上使用。缺点就是，当依赖对象比较多的时候，构造方法的参数列表会比较长。而通过反射构造对象的时候，对相同类型的参数的处理会比较困难，维护和使用上也比较麻烦。而且在Java中，构造方法无法被继承，无法设置默认值。对于非必须的依赖处理，可能需要引入多个构造方法，而参数数量的变动可能造成维护上的不便。 (3)setter方法注入。因为方法可以命名，所以setter方法注入在描述性上要比构造方法注入好一些。另外，setter方法可以被继承，允许设置默认值，而且有良好的IDE支持。缺点当然就是对象无法在构造完成后马上进入就绪状态.

Part3*:循环依赖注入问题

这是一个会经常遇到的一个问题，A依赖于B，B依赖于C，C依赖于A，那么在注入的时候就会出现循环，就像你和IOC Service Provider提出要和B一起去吃饭，而B等着和C吃饭，而C等着你去吃饭，这样就会形成一个死循环的状态，这种情况在Setter注入中很常见。 解决方案：https://blog.csdn.net/qq_42942472/article/details/107197043 本篇文章只是本人的一些见解以及看书时联想到的问题，如果有不足的地方请直接评论，十分感谢。