小伙伴们大家好,我是小牛肉,最近看 IoC 的源码头都看大了 😂,先出一篇读起来比较轻松的描述 IoC 概念的文章,原文来自这里 https://www.zhihu.com/question/23277575/answer/169698662,可能比喻不是特别贴切,不过在帮助理解 IoC 上面,还是比较通俗易懂的,然后我做了一些修改整理和总结,背诵版在文末~
要了解 控制反转( Inversion of Control,IoC), 我觉得有必要先了解软件设计的一个重要思想:依赖倒置原则(Dependency Inversion Principle )。
什么是依赖倒置原则?
假设我们设计一辆汽车:先设计轮子,然后根据轮子大小设计底盘,接着根据底盘设计车身,最后根据车身设计好整个汽车。这里就出现了一个 “依赖” 关系:汽车依赖车身,车身依赖底盘,底盘依赖轮子。
这样的设计看起来没问题,但是可维护性却很低。
假设设计完工之后,上司却突然说根据市场需求的变动,要我们把车子的轮子设计都改大一码。这下我们就蛋疼了:因为我们是根据轮子的尺寸设计的底盘,轮子的尺寸一改,底盘的设计就得修改;同样因为我们是根据底盘设计的车身,那么车身也得改,同理汽车设计也得改——整个设计几乎都得改!
我们现在换一种思路。我们先设计汽车的大概样子,然后根据汽车的样子来设计车身,根据车身来设计底盘,最后根据底盘来设计轮子。这时候,依赖关系就倒置过来了:轮子依赖底盘,底盘依赖车身,车身依赖汽车。
这时候,上司再说要改动轮子的设计,我们就只需要改动轮子的设计,而不需要动底盘,车身,汽车的设计了。
这就是依赖倒置原则 — 把原本的高层建筑依赖底层建筑“倒置”过来,变成底层建筑依赖高层建筑。高层建筑决定需要什么,底层去实现这样的需求,但是高层并不用管底层是怎么实现的。这样就不会出现前面的“牵一发动全身”的情况。
控制反转(Inversion of Control) 就是依赖倒置原则的一种具体的设计思路,或者说是一种可行的思想。而 IoC 的具体实现方法呢,就是 依赖注入(Dependency Injection)。这几种概念的关系大概如下:
为了理解这几个概念,我们还是用上面汽车的例子。只不过这次换成代码。我们先定义四个 Class,车,车身,底盘,轮胎。然后初始化这辆车,最后跑这辆车。代码结构如下:
这样,就相当于上面第一个例子,上层建筑依赖下层建筑——每一个类的构造函数都直接调用了底层代码的构造函数。假设我们需要改动一下轮胎(Tire)类,把它的尺寸变成动态的,而不是一直都是30。我们需要这样改:
由于我们修改了轮胎的定义,为了让整个程序正常运行,我们需要做以下改动:
由此我们可以看到,仅仅是为了修改轮胎的构造函数,这种设计却需要修改整个上层所有类的构造函数!在实际工程项目中,有的类可能会是几千个类的底层,如果每次修改这个类,我们都要修改所有以它作为依赖的类,那软件的维护成本就太高了。
所以我们需要进行控制反转(IoC),及上层控制下层,而不是下层控制着上层。我们用依赖注入(Dependency Injection)这种方式来实现控制反转。所谓依赖注入,就是把底层类作为参数传入上层类,实现上层类对下层类的“控制”。这里我们用构造方法传递的依赖注入方式重新写车类的定义:
这里我们再把轮胎尺寸变成动态的,同样为了让整个系统顺利运行,我们需要做如下修改:
看到没?这里**我只需要修改轮胎类就行了,不用修改其他任何上层类。**这显然是更容易维护的代码。
看到这里你应该能理解什么控制反转和依赖注入了。那什么是 控制反转容器(IoC Container) 呢?
其实上面的例子中,对车类进行初始化的那段代码发生的地方,就是控制反转容器(IoC 容器)做的事情。
显然你也应该观察到了,因为采用了依赖注入,在初始化的过程中就不可避免的会写大量的 new。这里 IoC 容器就解决了这个问题。这个容器可以自动对你的代码进行初始化,你只需要维护一个配置文件,而不用每次初始化一辆车都要亲手去写那一大段初始化的代码。这是引入 IoC Container 的第一个好处。
IoC Container的第二个好处是:我们在创建实例的时候不需要了解其中的细节。在上面的例子中,我们自己手动创建一个车 instance 时候,是从底层往上层 new 的:
这个过程中,我们需要了解整个 Car/Framework/Bottom/Tire 类构造函数是怎么定义的,才能一步一步 new/注入。
而 IoC Container 在进行这个工作的时候是反过来的,它先从最上层开始往下找依赖关系,到达最底层之后再往上一步一步 new(有点像深度优先遍历):
这里 IoC Container 可以直接隐藏具体的创建实例的细节,在我们来看它就像一个工厂:
我们就像是工厂的客户。我们只需要向工厂请求一个 Car 实例,然后它就给我们按照 Config 创建了一个 Car 实例。我们完全不用管这个 Car 实例是怎么一步一步被创建出来。
实际项目中,有的 Service Class 可能是十年前写的,有几百个类作为它的底层。假设我们新写的一个API需要实例化这个Service,我们总不可能回头去搞清楚这几百个类的构造函数吧?
IoC Container 的这个特性就很完美的解决了这类问题
因为这个架构要求你在写 class 的时候需要写相应的 Config 文件,所以你要初始化很久以前的 Service 类的时候,前人都已经写好了 Config 文件,你直接在需要用的地方注入这个 Service 就可以了。这大大增加了项目的可维护性且降低了开发难度。
最后我来总结下放上 IoC 的背诵版:
🥸 面试官:讲一下你对 IoC (依赖注入) 的理解 😎 小牛肉:首先,IoC(Inverse of Control,控制反转)在其他语言中也有应用,并非 Spring 特有,它是一种设计思想,基本概念就是将原本在程序中手动创建对象的控制权,交由 Spring 框架来管理。IoC 具体的实现方式是依赖注入。 简单的说之前我们在代码中创建一个对象是通过
new
关键字,而使用了Spring
之后,我们不在需要自己去new
一个对象了,而是直接通过容器里面去取出来,再将其自动注入到我们需要的对象之中,也就说创建对象的控制权不在我们程序员手上了,全部交由Spring
进行管理。 交给 Spring 管理的也称为 Bean,所有的 Bean 都被存储在一个 Map 集合中,这个 Map 集合也称为 IoC 容器。 将对象之间的相互依赖关系交给 IoC 容器来管理,并由 IoC 容器完成对象的注入。这样可以很大程度上简化应用的开发,把应用从复杂的依赖关系中解放出来。IoC 容器就像是一个工厂一样,当我们需要创建一个对象的时候,只需要配置好配置文件/注解即可,完全不用考虑对象是如何被创建出来的。 比如说,在实际项目中一个 Service 类可能有几百甚至上千个类作为它的底层,假如我们需要实例化这个 Service,你可能每次都要搞清这个 Service 所有底层类的构造函数,这显然过于繁琐。如果利用 IoC 的话,你只需要配置好,然后在需要的地方引用就行了,这大大增加了项目的可维护性且降低了开发难度。
心之所向,素履以往,我是小牛肉,小伙伴们下篇文章再见 👋