spring ioc有什么好处?

ioc是spring中最重要的特性,但是我们不一定清楚,为什么需要使用ioc?使用ioc能解决什么问题?能给我们的程序带来什么好处?

我之前研究过这个问题,但是始终没有系统的理解,直到看了知乎上的一篇回答才恍然大悟。我打算写篇读后感,加深理解。

感谢:https://www.zhihu.com/question/23277575

 

一、依赖倒置原则

要了解控制反转(Inversion of Control), 我们有必要先了解软件设计的一个重要思想:依赖倒置原则(Dependency Inversion Principle)。

什么是依赖倒置原则?

假设我们设计一辆汽车:先设计轮子,然后根据轮子大小设计底盘,接着根据底盘设计车身,最后根据车身设计好整个汽车。这里就出现了一个“依赖”关系:汽车依赖车身,车身依赖底盘,底盘依赖轮子。

111

这样的设计看起来似乎没有问题,但是可维护性却很差。

假设设计完工之后,上司却突然说根据市场需求的变动,要我们把车子的轮子设计都改大一码。

这下我们就蛋疼了:因为我们是根据轮子的尺寸设计的底盘,轮子的尺寸一改,底盘的设计就得修改;同样因为我们是根据底盘设计的车身,那么车身也得改,同理汽车设计也得改——整个设计几乎都得改!

所以我们换一种思路:先设计汽车的大概样子,然后根据汽车的样子来设计车身,根据车身来设计底盘,最后根据底盘来设计轮子。这时候,依赖关系就倒置过来了:轮子依赖底盘,底盘依赖车身,车身依赖汽车。

111

这时候,上司再说要改动轮子的设计,我们就只需要改动轮子的设计,而不需要动底盘,车身,汽车的设计了。

这就是依赖倒置原则,把原本的高层建筑依赖底层建筑“倒置”过来,变成底层建筑依赖高层建筑。高层建筑决定需要什么,底层去实现这样的需求,但是高层并不用管底层是怎么实现的。这样就不会出现前面的“牵一发动全身”的情况(其实就是解耦啦)。

二、控制反转

控制反转(Inversion of Control)是依赖倒置原则的一种代码设计的思路。具体采用的方法就是所谓的依赖注入(Dependency Injection)。概念的关系大概如下:

111

为了理解这几个概念,我们把上面的例子抽象成代码。先定义四个Class,车,车身,底盘,轮胎,然后初始化这辆车,最后让这辆车运行起来。

Car.java

这样,就相当于上面第一个例子,上层建筑依赖下层建筑,每一个类的构造函数都直接调用了底层代码的构造函数。

现在我们需要改动一下轮胎(Tire)类,把它的尺寸变成动态的,而不是一直都是30。我们需要这样改:

那么问题来了,Tire的构造方法改了,Bottom的构造方法也要跟着改(Bottom中调用的构造方法需要加上参数),同理,Frameword也要跟着改…最后会变成这样:

Car.java

我们可以看到,仅仅是为了修改轮胎的构造函数,这种设计却需要修改整个上层所有类的构造函数!

在软件工程中,这样的设计几乎是不可维护的。在实际工程项目中,有的类可能会是几千个类的底层,如果每次修改这个类,我们都要修改所有以它作为依赖的类,那软件的维护成本就太高了。

这就是为什么我们需要控制反转(IoC)。实现控制反转的方法就是依赖注入(Dependency Injection)。所谓的依赖注入,就是把底层类作为参数传入上层类,实现上层类对下层类的“控制”(这里我理解为并不是“上层依赖下层”,而是“上层控制下层”)。

我们尝试用依赖注入的方式(构造方法传递)重写车类的定义:

Car.java

我们再把轮胎尺寸变成动态的,需要做如下修改:

看到没有,这里我只需要修改Tire类就行了,不用修改其他任何上层类。这显然是更容易维护的代码。

不仅如此,在实际的工程中,这种设计模式还有利于不同组的协同合作和单元测试。比如开发这四个类的分别是四个不同的组,那么只要定义好了接口,四个不同的组可以同时进行开发而不相互受限制;而对于单元测试,如果我们要写Car类的单元测试,就只需要Mock一个Framework类传入Car就行了,不用把Framework, Bottom, Tire全部new一遍再来构造Car。

这里我们是采用的构造函数传入的方式进行的依赖注入。其实还有另外两种方法:Setter传递和接口传递。这里就不多讲了,核心思路都是一样的,都是为了实现控制反转。

这两种方式的补完:

Setter传递和接口传递进行依赖注入

三、控制反转容器

看到这里,你应该能理解什么控制反转和依赖注入了。那什么是控制反转容器(IoC Container)呢?

其实上面的例子中,对车类进行初始化的那段代码发生的地方(就是那段main方法),就是控制反转容器。

因为使用了依赖注入,在初始化的过程中就必须写大量的new。那么问题来了,如果一个类控制了成百上千个类,那岂不是要new(初始化)成百上千个对象?

这就对了,IoC容器的功能就是帮我们初始化对象。

IoC容器的第一个好处,就是可以自动帮助你的代码进行初始化。你只需要维护一个Configuration(可以是xml(spring中经典的xml配置),也可以是一段代码(spring中用于注入的注解)),就不用每次初始化一辆车都要亲手去写那一大段初始化的代码了。

IoC容器的第二个好处是:我们在创建实例的时候不需要了解其中的细节。

假如没有IoC容器,如果我们要创建一个类,要怎么做呢?只能自底而上一直new。

111

这个过程中,我们需要了解整个Car/Framework/Bottom/Tire类构造函数是怎么定义的,才能一步一步new/注入。

IoC容器在进行这个工作的时候是反过来的,它先从最上层开始往下找依赖关系,到达最底层之后再往上一步一步new(有点像深度优先遍历):

111

在这里IoC容器,可以直接隐藏具体的创建实例的细节,在我们来看它就像一个工厂:

111

之所以把IoC容器理解为一个工厂,是因为实现的功能类似于“工厂类”,我们想要创建一个Car实例,就直接“获得”了一个Car实例。IoC容器到底做了什么(按照Config一步一步创建了一个Car实例),过程有多么复杂,我们根本没必要知道。

实际项目中,有的Service Class可能是十年前写的,有几百个类作为它的底层。假设我们新写的一个API需要实例化这个Service,我们总不可能回头去搞清楚这几百个类的构造函数吧?IoC容器就很完美的解决了这类问题,大大增加了项目的可维护性,并且降低了开发难度。

四、总结

了解一个东西,需要明白这个东西能解决什么问题,怎样解决问题。

发表评论

电子邮件地址不会被公开。 必填项已用*标注