面试中浅谈Spring IOC

IOC控制反转。依赖注入。

借助第三方，然后实现对具有依赖关系的对象之间的解耦。

依赖注入(DI)和控制反转(IOC)是从不同的角度的描述的同一件事情，就是指通过引入IOC容器，利用依赖关系注入的方式，实现对象之间的解耦。

所谓依赖注入，就是由IOC容器在运行期间，动态地将某种依赖关系注入到对象之中。

 

说下自己的理解：

比如我们有很多个对象之间相互耦合，打个比方，对象A依赖B，对象A依赖对象D，对象B依赖对象C，对象C依赖对象D

四个对象相互耦合，比较复杂。

如果没有IOC的时候，那么对象A在初始化或者运行到某一点的时候，

自己必须主动去创建对象B或者使用已经创建的对象B。无论是创建还是使用对象B，控制权都在自己手上。

由于IOC容器的加入，对象A与对象B之间失去了直接联系，IOC 就像是一个粘合剂一样，把系统中的所有对象粘合在一起发挥。

所以，当对象A运行到需要对象B的时候，IOC容器会主动创建一个对象B注入到对象A需要的地方。

对象A获得依赖对象B的过程,由主动行为变为了被动行为，控制权颠倒过来了

这也就是IOC为什么叫做控制反转的原因。

 

IOC 的好处：

1、对对象进行解耦，彼此之间互不影响，只要保证自身的功能无误即可。

2、提高了模块的可复用性。

3、模块具有热插拔特性。IOC生成对象的方式转为外置方式，也就是把对象生成放在配置文件里进行定义，

这样，当我们更换一个实现子类将会变得很简单，只要修改配置文件就可以了，完全具有热插拨的特性。

 

IOC中技术（基本上不用说这一点，了解一下）

IOC中最基本的技术就是“反射(Reflection)”编程：，通俗来讲就是根据给出的类名（字符串方式）来动态地生成对象

 

需要注意的地方：（基本上不用说这一点，了解一下）

IOC容器生成对象是通过反射方式，在运行效率上有一定的损耗。

IOC框架产品(比如：Spring)来讲，需要进行大量的配制工作，比较繁琐，对于一些小的项目而言，客观上也可能加大一些工作成本。

IOC框架产品本身的成熟度需要进行评估，如果引入一个不成熟的IOC框架产品，那么会影响到整个项目，所以这也是一个隐性的风险。

一些工作量不大的项目或者产品，不太适合使用IOC框架产品。另外，如果团队成员的知识能力欠缺，对于IOC框架产品缺乏深入的理解，也不要贸然引入。

最后，特别强调运行效率的项目或者产品，也不太适合引入IOC框架产品

祝大家面试顺利！！！！！