你确定懂？彻底搞懂 控制反转（IoC Inversion of Control ）与依赖注入（DI Dependency Inversion Principle ）
说明
Spring框架，核心就是IoC容器。要掌握Spring框架，就必须要理解控制反转的思想以及依赖注入的实现方式。下面，我们将围绕下面几个问题来探讨控制反转与依赖注入的关系以及在Spring中如何应用。
什么是控制反转？
什么是依赖注入？
它们之间有什么关系？
如何在Spring框架中应用依赖注入？
1. 控制反转
在讨论控制反转之前，我们先来看看软件系统中耦合的对象。
图1：软件系统中耦合的对象
从图中可以看到，软件中的对象就像齿轮一样，协同工作，但是互相耦合，一个零件不能正常工作，整个系统就崩溃了。这是一个强耦合的系统。齿轮组中齿轮之间的啮合关系,与软件系统中对象之间的耦合关系非常相似。对象之间的耦合关系是无法避免的，也是必要的，这是协同工作的基础。现在，伴随着工业级应用的规模越来越庞大，对象之间的依赖关系也越来越复杂，经常会出现对象之间的多重依赖性关系，因此，架构师和设计师对于系统的分析和设计，将面临更大的挑战。对象之间耦合度过高的系统，必然会出现牵一发而动全身的情形。
为了解决对象间耦合度过高的问题，软件专家Michael Mattson提出了IoC理论，用来实现对象之间的“解耦”。
控制反转（Inversion of Control）是一种是面向对象编程中的一种设计原则，用来减低计算机代码之间的耦合度。其基本思想是：借助于“第三方”实现具有依赖关系的对象之间的解耦。
图2：IoC解耦过程
由于引进了中间位置的“第三方”，也就是IOC容器，使得A、B、C、D这4个对象没有了耦合关系，齿轮之间的传动全部依靠“第三方”了，全部对象的控制权全部上缴给“第三方”IOC容器，所以，IOC容器成了整个系统的关键核心，它起到了一种类似“粘合剂”的作用，把系统中的所有对象粘合在一起发挥作用，如果没有这个“粘合剂”，对象与对象之间会彼此失去联系，这就是有人把IOC容器比喻成“粘合剂”的由来。
我们再来看看，控制反转(IOC)到底为什么要起这么个名字？我们来对比一下：
软件系统在没有引入IOC容器之前，如图1所示，对象A依赖于对象B，那么对象A在初始化或者运行到某一点的时候，自己必须主动去创建对象B或者使用已经创建的对象B。无论是创建还是使用对象B，控制权都在自己手上。
软件系统在引入IOC容器之后，这种情形就完全改变了，如图2所示，由于IOC容器的加入，对象A与对象B之间失去了直接联系，所以，当对象A运行到需要对象B的时候，IOC容器会主动创建一个对象B注入到对象A需要的地方。
通过前后的对比，我们不难看出来：对象A获得依赖对象B的过程,由主动行为变为了被动行为，控制权颠倒过来了，这就是“控制反转”这个名称的由来。控制反转不只是软件工程的理论，在生活中我们也有用到这种思想。再举一个现实生活的
例子：
海尔公司作为一个电器制商需要把自己的商品分销到全国各地，但是发现，不同的分销渠道有不同的玩法，于是派出了各种销售代表玩不同的玩法，随着渠道越来越多，发现，每增加一个渠道就要新增一批人和一个新的流程，严重耦合并依赖各渠道商的玩法。实在受不了了，于是制定业务标准，开发分销信息化系统，只有符合这个标准的渠道商才能成为海尔的分销商。让各个渠道商反过来依赖自己标准。反转了控制，倒置了依赖。
我们把海尔和分销商当作软件对象，分销信息化系统当作IOC容器，可以发现，在没有IOC容器之前，分销商就像图1中的齿轮一样，增加一个齿轮就要增加多种依赖在其他齿轮上，势必导致系统越来越复杂。开发分销系统之后，所有分销商只依赖分销系统，就像图2显示那样，可以很方便的增加和删除齿轮上去。
2. 依赖注入
依赖注入就是将实例变量传入到一个对象中去(Dependency injection means giving an object its instance variables)。
2.1 什么是依赖
如果在 Class A 中，有 Class B 的实例，则称 Class A 对 Class B 有一个依赖。例如下面类 Human 中用到一个 Father 对象，我们就说类 Human 对类 Father 有一个依赖。
public class Human {...Father father;...public Human() {father = new Father();}
}
仔细看这段代码我们会发现存在一些问题：
- 如果现在要改变 father 生成方式，如需要用new Father(String name)初始化 father，需要修改 Human 代码；
- 如果想测试不同 Father 对象对 Human 的影响很困难，因为 father 的初始化被写死在了 Human 的构造函数中；
- 如果new Father()过程非常缓慢，单测时我们希望用已经初始化好的 father 对象 Mock 掉这个过程也很困难。
2.2 依赖注入
上面将依赖在构造函数中直接初始化是一种 Hard init 方式，弊端在于两个类不够独立，不方便测试。我们还有另外一种 Init 方式，如下：
public class Human {...Father father;...public Human(Father father) {this.father = father;}
}
上面代码中，我们将 father 对象作为构造函数的一个参数传入。在调用 Human 的构造方法之前外部就已经初始化好了 Father 对象。像这种非自己主动初始化依赖，而通过外部来传入依赖的方式，我们就称为依赖注入。
现在我们发现上面 1 中存在的两个问题都很好解决了，简单的说依赖注入主要有两个好处：
- 解耦，将依赖之间解耦。
- 因为已经解耦，所以方便做单元测试，尤其是 Mock 测试。
2.3 控制反转和依赖注入的关系
我们已经分别解释了控制反转和依赖注入的概念。有些人会把控制反转和依赖注入等同，但实际上它们有着本质上的不同。
- 控制反转是一种思想
- 依赖注入是一种设计模式
IoC框架使用依赖注入作为实现控制反转的方式，但是控制反转还有其他的实现方式，例如说ServiceLocator，所以不能将控制反转和依赖注入等同。
2.4 Spring中的依赖注入
上面我们提到，依赖注入是实现控制反转的一种方式。下面我们结合Spring的IoC容器，简单描述一下这个过程。
class MovieLister...private MovieFinder finder;public void setFinder(MovieFinder finder) {this.finder = finder;}class ColonMovieFinder...public void setFilename(String filename) {this.filename = filename;}
我们先定义两个类，可以看到都使用了依赖注入的方式，通过外部传入依赖，而不是自己创建依赖。那么问题来了，谁把依赖传给他们，也就是说谁负责创建finder，并且把finder传给MovieLister。答案是Spring的IoC容器。
要使用IoC容器，首先要进行配置。这里我们使用xml的配置，也可以通过代码注解方式配置。下面是spring.xml的内容
<beans><bean id="MovieLister" class="spring.MovieLister"><property name="finder"><ref local="MovieFinder"/></property></bean><bean id="MovieFinder" class="spring.ColonMovieFinder"><property name="filename"><value>movies1.txt</value></property></bean>
</beans>
在Spring中，每个bean代表一个对象的实例，默认是单例模式，即在程序的生命周期内，所有的对象都只有一个实例，进行重复使用。通过配置bean，IoC容器在启动的时候会根据配置生成bean实例。具体的配置语法参考Spring文档。这里只要知道IoC容器会根据配置创建MovieFinder，在运行的时候把MovieFinder赋值给MovieLister的finder属性，完成依赖注入的过程。
下面给出测试代码
public void testWithSpring() throws Exception {ApplicationContext ctx = new FileSystemXmlApplicationContext("spring.xml");//1MovieLister lister = (MovieLister) ctx.getBean("MovieLister");//2Movie[] movies = lister.moviesDirectedBy("Sergio Leone");assertEquals("Once Upon a Time in the West", movies[0].getTitle());
}
- 根据配置生成ApplicationContext，即IoC容器。
- 从容器中获取MovieLister的实例。
2.5 总结
控制反转是一种在软件工程中解耦合的思想，调用类只依赖接口，而不依赖具体的实现类，减少了耦合。控制权交给了容器，在运行的时候才由容器决定将具体的实现动态的“注入”到调用类的对象中。
依赖注入是一种设计模式，可以作为控制反转的一种实现方式。依赖注入就是将实例变量传入到一个对象中去(Dependency injection means giving an object its instance variables)。
通过IoC框架，类A依赖类B的强耦合关系可以在运行时通过容器建立，也就是说把创建B实例的工作移交给容器，类A只管使用就可以。
3 汽车与轮子的关系 理解IoC 和 DI
要了解控制反转( Inversion of Control ), 我觉得有必要先了解软件设计的一个重要思想：依赖倒置原则（Dependency Inversion Principle ）。
3.1 什么是依赖倒置原则？
假设我们设计一辆汽车：先设计轮子，然后根据轮子大小设计底盘，接着根据底盘设计车身，最后根据车身设计好整个汽车。这里就出现了一个“依赖”关系：汽车依赖车身，车身依赖底盘，底盘依赖轮子。
这样的设计看起来没问题，但是可维护性却很低。假设设计完工之后，上司却突然说根据市场需求的变动，要我们把车子的轮子设计都改大一码。这下我们就蛋疼了：因为我们是根据轮子的尺寸设计的底盘，轮子的尺寸一改，底盘的设计就得修改；同样因为我们是根据底盘设计的车身，那么车身也得改，同理汽车设计也得改——整个设计几乎都得改！
我们现在换一种思路。我们先设计汽车的大概样子，然后根据汽车的样子来设计车身，根据车身来设计底盘，最后根据底盘来设计轮子。这时候，依赖关系就倒置过来了：轮子依赖底盘， 底盘依赖车身， 车身依赖汽车。
这时候，上司再说要改动轮子的设计，我们就只需要改动轮子的设计，而不需要动底盘，车身，汽车的设计了。
这就是依赖倒置原则——把原本的高层建筑依赖底层建筑“倒置”过来，变成底层建筑依赖高层建筑。高层建筑决定需要什么，底层去实现这样的需求，但是高层并不用管底层是怎么实现的。这样就不会出现前面的“牵一发动全身”的情况。
3.2 控制反转 Inversion of Control
就是依赖倒置原则的一种代码设计的思路。具体采用的方法就是所谓的依赖注入（Dependency Injection）。其实这些概念初次接触都会感到云里雾里的。说穿了，这几种概念的关系大概如下：
为了理解这几个概念，我们还是用上面汽车的例子。只不过这次换成代码。我们先定义四个Class，车，车身，底盘，轮胎。然后初始化这辆车，最后跑这辆车。代码结构如下：
这样，就相当于上面第一个例子，上层建筑依赖下层建筑——每一个类的构造函数都直接调用了底层代码的构造函数。假设我们需要改动一下轮胎（Tire）类，把它的尺寸变成动态的，而不是一直都是30。我们需要这样改：
由于我们修改了轮胎的定义，为了让整个程序正常运行，我们需要做以下改动：
由此我们可以看到，仅仅是为了修改轮胎的构造函数，这种设计却需要修改整个上层所有类的构造函数！在软件工程中，这样的设计几乎是不可维护的——在实际工程项目中，有的类可能会是几千个类的底层，如果每次修改这个类，我们都要修改所有以它作为依赖的类，那软件的维护成本就太高了。
所以我们需要进行控制反转（IoC），及上层控制下层，而不是下层控制着上层。我们用依赖注入（Dependency Injection）这种方式来实现控制反转。所谓依赖注入，就是把底层类作为参数传入上层类，实现上层类对下层类的“控制”。这里我们用构造方法传递的依赖注入方式重新写车类的定义：
这里我们再把轮胎尺寸变成动态的，同样为了让整个系统顺利运行，我们需要做如下修改：
看到没？这里我只需要修改轮胎类就行了，不用修改其他任何上层类。这显然是更容易维护的代码。不仅如此，在实际的工程中，这种设计模式还有利于不同组的协同合作和单元测试：比如开发这四个类的分别是四个不同的组，那么只要定义好了接口，四个不同的组可以同时进行开发而不相互受限制；而对于单元测试，如果我们要写Car类的单元测试，就只需要Mock一下Framework类传入Car就行了，而不用把Framework, Bottom, Tire全部new一遍再来构造Car。
3.3 Setter传递和接口传递 的依赖注入
这里我们是采用的构造函数传入的方式进行的依赖注入。其实还有另外两种方法：Setter传递和接口传递。这里就不多讲了，核心思路都是一样的，都是为了实现控制反转。
看到这里你应该能理解什么控制反转和依赖注入了。
4 控制反转容器(IoC Container)
那什么是控制反转容器(IoC Container)呢？其实上面的例子中，对车类进行初始化的那段代码发生的地方，就是控制反转容器。
显然你也应该观察到了，因为采用了依赖注入，在初始化的过程中就不可避免的会写大量的new。这里IoC容器就解决了这个问题。这个容器可以自动对你的代码进行初始化，你只需要维护一个Configuration（可以是xml可以是一段代码），而不用每次初始化一辆车都要亲手去写那一大段初始化的代码。这是引入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就可以了。这大大增加了项目的可维护性且降低了开发难度。
5 解耦的思路
消费者X需要消费类Y来完成某项工作。那都是自然而然的，但是X真的需要知道它使用Y吗？
知道X使用具有Y的行为，方法，属性等的东西而又不知道是谁真正实现了行为，这还不够吗？
通过提取X在Y中使用的行为的抽象定义（如下图I所示），并让消费者X使用该实例代替Y，它可以继续执行其操作而不必了解有关Y的细节。
在上面的图示中，Y实现了I，而X使用了I的实例。尽管X仍然很可能仍使用Y，但有趣的是X并不知道这一点。它只知道它使用实现I的东西。
参考
https://www.zhihu.com/question/23277575
https://www.jianshu.com/p/07af9dbbbc4b
https://martinfowler.com/articles/injection.html
http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/
你确定懂？彻底搞懂 控制反转（IoC Inversion of Control ）与依赖注入（DI Dependency Inversion Principle ）相关推荐
- 控制反转(Ioc)和依赖注入(DI)
控制反转IOC, 全称 "Inversion of Control".依赖注入DI, 全称 "Dependency Injection". 面向的问题:软件开发 ...
- 控制反转(IoC)与依赖注入(DI)详解
文章目录 什么是控制反转(IoC) 控制反转(IoC)有什么作用 控制反转(IoC)是怎么分类的 依赖注入 接口注入 Setter方法注入 构造器注入 依赖查找 上下文依赖查找(Contextuali ...
- 依赖倒置(DIP),控制反转(IoC)与依赖注入(DI)
DIP,IoC与DI概念解析 依赖倒置 DIP(Dependency Inversion Principle) DIP的两大原则: 1.高层模块不应该依赖于低层模块,二者都应该依赖于抽象. 2.抽象不 ...
- 前端解读控制反转(IOC)
前言 随着前端承担的职责越来越重,前端应用向着复杂化.规模化的方向发展.大型项目模块化是一种趋势,不可避免模块之间要相互依赖,此外还有很多第三方包.这样的话如何去管理这些繁杂的文件,是一个不可避免的话 ...
- [教程]控制反转(IoC)与依赖注入(DI)
来源: http://zhangjunhd.blog.51cto.com/113473/126530/ 挺简单的,说的也很清楚 ※IoC/DI 依赖Java的反射机制 1.控制反转(Inversion ...
- 控制反转(IoC) ？ 工厂模式？
不知道大家还记不记得当年程杰的<大话设计模式>了,最近一直想搞明白控制反转到底是怎么回事,刚刚觉得高大上了一点,然后再进一步去学习去对比的时候才发现,以前早就接触过这类的思想,设计原则的依 ...
- java-12:spring MVC - 控制反转IOC，依赖注入DI
学习spring框架之前,先理解几个概念: 1.第一部分:依赖倒置原则 2.第二部分:控制反转,控制反转容器(实例) 3.第三部分:控制反转,控制反转容器(全面理解,面试题) 综合性理解:控制反转(I ...
- 浅析Spring——控制反转IoC
目录 1. IoC理论推导 2. 什么是IoC? 3. 引入DI 4. IoC容器 5. 注入对象的四种方法 1.基于接口 2.基于setter 3.基于构造函数 4.基于注解 6. 两种IoC实现方 ...
- 庖丁解牛Nop:控制反转--IOC和DI
IOC中文名被称作控制反转(Inversion of Control),DI被称为依赖注入(Dependency Injection); 使用控制反转开发模式是先开发接口,然后再实现类.这种方法却可以 ...
- 控制反转IOC与依赖注入DI
为什么80%的码农都做不了架构师?>>> 1. IoC理论的背景 我们都知道,在采用面向对象方法设计的软件系统中,它的底层实现都是由N个对象组成的,所有的对象通过彼此的合作,最 ...
最新文章
- fiddler教程：抓包带锁的怎么办？HTTPS抓包介绍。
- Android基础之Java接口
- BZOJ1444: [Jsoi2009]有趣的游戏（Trie图，矩乘）
- TMS320DM642学习----第一篇（硬件连接）
- k8s往secret里导入证书_k8s中secret解析
- 事务对性能影响_DRDS 柔性事务漫谈
- http缓存协议详解
- Java核心技术卷1: 多线程
- 【CCCC】L2-018 多项式A除以B (25分)，多项式除法
- python输入一个字符串、计算其中小写字符的个数_编写程序,输入一个字符串,统计其中大小写字母数字和其他符号的个数并输出,要求统计过程在函数COUNT中进行...
- python_thrift
- GBS服装分床裁剪计划软件V4.0正式发布
- 密度聚类之DBSCAN聚类算法
- 7.1立体环绕追踪音效｜专属个性调音台，这副头戴电竞耳机有点料
- 【论文阅读】水下机器人控制视觉伺服部分
- 开源三轴云台EVVGC（simple BGC）分析
- android微信登录用户绑定,微信授权登陆接入第三方App（步骤总结）Android
- Java job interview:WinForm界面特效设计案例导航图分享
- HTTP协议（深入http请求）
- 计算机毕业设计，vue+springboot的农产品溯源系统，内附源码