前言
相信在面试中,只要问到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
public interface Game {
void download();
void install();
void play();
}
Cs
public class Cs implements Game {
@Override
public void download() {
System.out.println("下载Cs");
}
@Override
public void install() {
System.out.println("安装Cs");
}
@Override
public void play() {
System.out.println("我在玩Cs");
}
}
Gta5
public class Gta5 implements Game {
@Override
public void download() {
System.out.println("下载GTA5");
}
@Override
public void install() {
System.out.println("安装GTA5");
}
@Override
public void play() {
System.out.println("GTA5玩的很开心");
}
}
Player
public class Player {
public void play(){
Game game = new Gta5();
game.download();
game.install();
game.play();
}
}
上面代码中可以看到Player
和Gta5
(这可以是任意一个实现了Game接口
的类型)之间存在强耦合关系,并且在编译期间就指定好了。当Gta5
发生改变时,Player
也需要做出相应的改变。由于每个玩家玩的游戏都是不一样的,如果要适应需求,那我们需要不停的进行修改。显然这是不符合规范的。
public class Player {
private Game game;.
public Player(Game game) {
this.game = game;
}
public void play(){
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就没有这个烦恼了,修改相应的配置就可以了,代码完全不需要进行改动。
<bean id="gta5" class="com.hxh.service.impl.Gta5">
<constructor-arg name="username" value="不一样的科技宅"></constructor-arg>
</bean>
我们可以这样回答。
IOC翻译过来的意思是控制反转,也被称作为依赖注入。通过将主动创建对象过程变成了被动接收,编译期依赖变成了运行时依赖,以此来降低对象之间的耦合度。为了实现依赖注入,需要在XML内配置好依赖关系,并且将对象实例化,销毁,等过程统一交由IOC容器进行管理。这样的话,由于IOC容器将类的实例化过程透明化,并且创建的是单例对象,所以在方便调用方的使用同时,还减少了内存的占用。
参考文章
结尾
写完内心有点忐忑,如果有觉得写的不对的地方,希望能在评论区指出来,感谢。
如果觉得对你有帮助,可以多多评论,多多点赞哦,也可以到我的主页看看,说不定有你喜欢的文章,也可以随手点个关注哦,谢谢。
我是不一样的科技宅,每天进步一点点,体验不一样的生活。我们下期见!