前言
相信在面试中，只要问到Spring，基本都会抛出一个问题，说说你对Spring IOC理解吧？虽然在日常的开发经常会使用到，但是要回答起来，并不简单。大脑经过简单的头脑风暴后，蹦出了控制反转、依赖注入这样的词语。显然这些并不是面试官想听的。
IOC是什么？
IOC（Inverse of Contro）控制反转，有时候也被称为DI（Dependency injection）依赖注入，它是一种降低对象耦合关系的一种设计思想。
2004年，Martin Fowler探讨了一个问题，既然IOC是控制反转，那么到底是哪些方面的控制被反转了呢？，经过详细地分析和论证后，他得出了答案：获得依赖对象的过程被反转了。控制被反转之后，获得依赖对象的过程由自身管理变为了由IOC容器主动注入。于是，他给“控制反转”取了一个更合适的名字叫做“依赖注入（Dependency Injection）”。他的这个答案，实际上给出了实现IOC的方法：注入。所谓依赖注入就是：由IOC容器在运行期间，动态地将某种依赖关系注入到对象之中。
控制反转（IOC）是一种思想，而依赖注入（Dependency Injection）则是实现这种思想的方法。
我的理解
假如有这样一个场景，你一时兴起你想玩GTA5，这时候你需要先去下载GTA5，然后安装好GTA5，安装完以后你就能开心的玩耍了。玩了一段时间你可以能觉得有点腻了，又想玩CS了，很显然你又要先去下载，然后安装，才能愉快的玩耍。多经历几次，你可能就觉得有点烦了，你就在想要是有个游戏仓库就好了，能自动的帮我下载和安装游戏。这样我想玩啥，游戏仓库直接给我就可以了。而IOC就是这个游戏仓库。
Game
publicinterfaceGame{
voiddownload();
voidinstall();
voidplay();
}
Cs
publicclassCsimplementsGame{
@Override
publicvoiddownload(){
System.out.println("下载Cs");
}
@Override
publicvoidinstall(){
System.out.println("安装Cs");
}
@Override
publicvoidplay(){
System.out.println("我在玩Cs");
}
}
Gta5
publicclassGta5implementsGame{
@Override
publicvoiddownload(){
System.out.println("下载GTA5");
}
@Override
publicvoidinstall(){
System.out.println("安装GTA5");
}
@Override
publicvoidplay(){
System.out.println("GTA5玩的很开心");
}
}
Player
publicclassPlayer{
publicvoidplay(){
Gamegame=newGta5();
game.download();
game.install();
game.play();
}
}
上面代码中可以看到Player和Gta5（这可以是任意一个实现了Game接口的类型）之间存在强耦合关系，并且在编译期间就指定好了。当Gta5发生改变时，Player也需要做出相应的改变。由于每个玩家玩的游戏都是不一样的，如果要适应需求，那我们需要不停的进行修改。显然这是不符合规范的。
publicclassPlayer{
privateGamegame;.
publicPlayer(Gamegame){
this.game=game;
}
publicvoidplay(){
game.play();
}
}
将Player的代码根据依赖倒置原则，程序要依赖于抽象接口，不要依赖于具体实现进行修改。这样大大降低了Player和具体Game的实现类的耦合度。这个时候我们可以发现，原本需要在Player内对Game具体实现类进行实例化，现在变成了由外部传入。假如我传个Gat5进去，他就在玩Gta5，把Gta5变成Cs，他就在玩Cs了。Player不需要进行任何改变。
这个时候，我们再回过头来看看的定义。
- 控制反转：获得依赖对象的过程由自身管理变为了由IOC容器主动注入。
- 依赖注入：由IOC容器，在运行期间，动态地将某种依赖关系注入到对象之中。
白话一下
原本呢，我想玩游戏，我必须要先去下载好游戏，等到安装完成以后，才能开始玩。有了游戏仓库以后，我只需要告诉它，我玩啥游戏就可以了，它就会帮我下载并安装好游戏，等到我想玩的时候就能直接玩了。
原本呢，我需要在Player内自己的去实例化Game的实现类。现在呢，只需要在XML内配置好相应的依赖关系。假如配置的是Gta5。等到Player被实例化的时候，IOC就会将Gta5注入进来了。至于Gta5是如何被实例化的Player完全不需要关心。
概括一下：就是主动创建对象过程变成了被动接收，编译期依赖变成了运行时依赖，从而达到了对象之间的松耦合。
为什么要使用IOC？好处在哪里？
很显然，IOC的作用是降低对象和对象之间的耦合度，这和我们所期望高内聚，低耦合的设计思想是一致的嘛，所以能降低耦合当然要使用啊。好处有如下几点：
- 将类实例化的过程透明化，方便调用方使用。
- IOC容器使用单例模式管理对象，效率高，可以减少内存的占用。当然也通过配置可以实现多例。
- 依赖关系统一管理，方便修改。
IOC和工厂模式的区别？
不知道会不会有小伙伴吐槽，看了半天IOC不就是个工厂嘛，都是将类实例化的过程透明化，方便调用方使用。其实还是有所区别。当需求发生改变的时候，工厂模式需要修改相应的类才能实现，然而IOC是通过反射机制来实现的，不需要我们重新编译代码，因为它的对象都是动态生成的。
举个简单的例子，假如xx类的构造参数发生改变了，工厂就必须要修改对应的创建过程。然而IOC就没有这个烦恼了，修改相应的配置就可以了，代码完全不需要进行改动。
<beanid="gta5"class="com.hxh.service.impl.Gta5">
<constructor-argname="username"value="不一样的科技宅"></constructor-arg>
</bean>
我们可以这样回答。
IOC翻译过来的意思是控制反转，也被称作为依赖注入。通过将主动创建对象过程变成了被动接收，编译期依赖变成了运行时依赖，以此来降低对象之间的耦合度。为了实现依赖注入，需要在XML内配置好依赖关系，并且将对象实例化，销毁，等过程统一交由IOC容器进行管理。这样的话，由于IOC容器将类的实例化过程透明化，并且创建的是单例对象，所以在方便调用方的使用同时，还减少了内存的占用。
参考文章
- 浅谈IOC--说清楚IOC是什么
结尾
写完内心有点忐忑，如果有觉得写的不对的地方，希望能在评论区指出来，感谢。
如果觉得对你有帮助，可以多多评论，多多点赞哦，也可以到我的主页看看，说不定有你喜欢的文章，也可以随手点个关注哦，谢谢。
,
