spring概念理解之IOC(控制反转)
这是Spring中的有特点的一部份。IoC又被翻译成“控制反转”，也不知道是谁翻译得这么别扭，感觉很深奥的词。其实，原理很简单，用一句通俗的话来说：就是用XML来定义生成的对象。IoC其实是一种设计模式，Spring只是实现了这种设计模式。
这种设计模式是怎么来的呢？是实践中逐渐形成的。
第一阶段：用普通的无模式来写Java程序。一般初学者都要经过这个阶段。
第二阶段：频繁的开始使用接口，这时，接口一般都会伴随着使用工厂模式。
第三阶段：使用IoC模式。工厂模式还不够好：（1）因为的类的生成代码写死在程序里，如果你要换一个子类，就要修改工厂方法。（2）一个接口常常意味着一个生成工厂，会多出很多工厂类。
可以把IoC模式看做是工厂模式的升华，可以把IoC看作是一个大工厂，只不过这个大工厂里要生成的对象都是在XML文件中给出定义的，然后利用Java的“反射”编程，根据XML中给出的类名生成相应的对象。从实现来看，IoC是把以前在工厂方法里写死的对象生成代码，改变为由XML文件来定义，也就是把工厂和对象生成这两者独立分隔开来，目的就是提高灵活性和可维护性。
这里引用知乎的例子：Spring IoC有什么好处呢？
要了解控制反转( Inversion of Control ), 我觉得有必要先了解软件设计的一个重要思想：依赖倒置原则（Dependency Inversion Principle ）。
什么是依赖倒置原则？假设我们设计一辆汽车：先设计轮子，然后根据轮子大小设计底盘，接着根据底盘设计车身，最后根据车身设计好整个汽车。这里就出现了一个“依赖”关系：汽车依赖车身，车身依赖底盘，底盘依赖轮子。
这样的设计看起来没问题，但是可维护性却很低。假设设计完工之后，上司却突然说根据市场需求的变动，要我们把车子的轮子设计都改大一码。这下我们就蛋疼了：因为我们是根据轮子的尺寸设计的底盘，轮子的尺寸一改，底盘的设计就得修改；同样因为我们是根据底盘设计的车身，那么车身也得改，同理汽车设计也得改——整个设计几乎都得改！
我们现在换一种思路。我们先设计汽车的大概样子，然后根据汽车的样子来设计车身，根据车身来设计底盘，最后根据底盘来设计轮子。这时候，依赖关系就倒置过来了：轮子依赖底盘， 底盘依赖车身， 车身依赖汽车。
这时候，上司再说要改动轮子的设计，我们就只需要改动轮子的设计，而不需要动底盘，车身，汽车的设计了。
这就是依赖倒置原则——把原本的高层建筑依赖底层建筑“倒置”过来，变成底层建筑依赖高层建筑。高层建筑决定需要什么，底层去实现这样的需求，但是高层并不用管底层是怎么实现的。这样就不会出现前面的“牵一发动全身”的情况。
控制反转（Inversion of Control） 就是依赖倒置原则的一种代码设计的思路。具体采用的方法就是所谓的依赖注入（Dependency Injection）。其实这些概念初次接触都会感到云里雾里的。说穿了，这几种概念的关系大概如下：
为了理解这几个概念，我们还是用上面汽车的例子。只不过这次换成代码。我们先定义四个Class，车，车身，底盘，轮胎。然后初始化这辆车，最后跑这辆车。代码结构如下：
这样，就相当于上面第一个例子，上层建筑依赖下层建筑——每一个类的构造函数都直接调用了底层代码的构造函数。假设我们需要改动一下轮胎（Tire）类，把它的尺寸变成动态的，而不是一直都是30。我们需要这样改：
由于我们修改了轮胎的定义，为了让整个程序正常运行，我们需要做以下改动：
由此我们可以看到，仅仅是为了修改轮胎的构造函数，这种设计却需要修改整个上层所有类的构造函数！在软件工程中，这样的设计几乎是不可维护的——在实际工程项目中，有的类可能会是几千个类的底层，如果每次修改这个类，我们都要修改所有以它作为依赖的类，那软件的维护成本就太高了。
所以我们需要进行控制反转（IoC），及上层控制下层，而不是下层控制着上层。我们用依赖注入（Dependency Injection）这种方式来实现控制反转。所谓依赖注入，就是把底层类作为参数传入上层类，实现上层类对下层类的“控制”。这里我们用构造方法传递的依赖注入方式重新写车类的定义：
这里我们再把轮胎尺寸变成动态的，同样为了让整个系统顺利运行，我们需要做如下修改：
看到没？这里我只需要修改轮胎类就行了，不用修改其他任何上层类。这显然是更容易维护的代码。不仅如此，在实际的工程中，这种设计模式还有利于不同组的协同合作和单元测试：比如开发这四个类的分别是四个不同的组，那么只要定义好了接口，四个不同的组可以同时进行开发而不相互受限制；而对于单元测试，如果我们要写Car类的单元测试，就只需要Mock一下Framework类传入Car就行了，而不用把Framework, Bottom, Tire全部new一遍再来构造Car。
这里我们是采用的构造函数传入的方式进行的依赖注入。其实还有另外两种方法：Setter传递和接口传递。这里就不多讲了，核心思路都是一样的，都是为了实现控制反转。
看到这里你应该能理解什么控制反转和依赖注入了。那什么是控制反转容器(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就可以了。这大大增加了项目的可维护性且降低了开发难度。
这里只是很粗略的讲了一下我自己对IoC和DI的理解。主要的目的是在于最大限度避免晦涩难懂的专业词汇，用尽量简洁，通俗，直观的例子来解释这些概念。如果让大家能有一个类似“哦！原来就是这么个玩意嘛！”的印象，我觉得就OK了。想要深入了解的话，可以上网查阅一些更权威的资料。这里推荐一下 Dependency injection 和 Inversion of Control Containers and the Dependency Injection pattern 这两篇文章，讲的很好很详细。
IoC最大的好处是什么？因为把对象生成放在了XML里定义，所以当我们需要换一个实现子类将会变成很简单（一般这样的对象都是现实于某种接口的），只要修改XML就可以了，这样我们甚至可以实现对象的热插拨（有点象USB接口和SCIS硬盘了）。
IoC最大的缺点是什么？（1）生成一个对象的步骤变复杂了（其实上操作上还是挺简单的），对于不习惯这种方式的人，会觉得有些别扭和不直观。（2）对象生成因为是使用反射编程，在效率上有些损耗。但相对于IoC提高的维护性和灵活性来说，这点损耗是微不足道的，除非某对象的生成对效率要求特别高。（3）缺少IDE重构操作的支持，如果在Eclipse要对类改名，那么你还需要去XML文件里手工去改了，这似乎是所有XML方式的缺憾所在。
总的来说IoC无论原理和实现都还算是很简单的。一些人曾认为IoC没什么实际作用，这种说法是可以理解的，因为如果你在编程中很少使用接口，或很少使用工厂模式，那么你根本就没有使用IoC的强烈需要，也不会体会到IoC可贵之处。有些人也说要消除工厂模式、单例模式，但是都语焉不详、人云亦云。但如果你看到IoC模式和用上Spring，那么工厂模式和单例模式的确基本上可以不用了。但它消失了吗？没有！Spring的IoC实现本身就是一个大工厂，其中也包含了单例对象生成方式，只要用一个设置就可以让对象生成由普通方式变单一实例方式，非常之简单。
总结：
（1）IoC原理很简单，作用的针对性也很强，不要把它看得很玄乎。
（2）要理解IoC，首先要了解“工厂、接口、反射”这些概念。
spring概念理解之IOC(控制反转)相关推荐
- 【Spring第二篇】IOC:控制反转
IOC:控制反转 什么是IOC? 举个例子,我们有一个UserDao接口类,并且有三个UserDao实现类,分别是MysqlUserDaoImpl.OracleUserDaoImpl.UserDa ...
- 简述控制反转ioc_阅读Spring源码：IOC控制反转前的处理
温馨提示:要怀着 这个世界很美好 的心态去看~ 技术经验交流:点击入群 ClassPathXmlApplicationContext的注册方式 源码分析基于Spring4.3 从ClassPathXm ...
- Spring→简介核心作用范围、框架、接口编程、IOC控制反转、单元测试、Bean容器、注入、作用域、生命周期、自动装配注入、自动扫描@注解
官网 https://spring.io/ 文档 https://spring.io/projects/spring-framework Spring框架 框架 接口 IOC控制反转 单元测试 Bea ...
- Spring框架中IoC(控制反转)的原理
一.IoC的基础知识以及原理: 1.IoC理论的背景:在采用面向对象方法设计的软件系统中,底层实现都是由N个对象组成的,所有的对象通过彼此的合作,最终实现系统的业务逻辑.即软件系统中对象之间的耦合,对 ...
- spring ioc控制反转
一. 什么是spring,它能够做什么? Spring是一个开源框架,它由Rod Johnson创建.它是为了解决企业应用开发的复杂性而创建的. Spring使用基本的JavaBean来完成以前只可能 ...
- Spring的ioc控制反转
spring介绍 Spring的出现是为了取代EJB(Enterprise JavaBean)的臃肿.低效.脱离现实的缺点. Spring致力于J2EE应用的各层(表现层.业务层.持久层)的解决方案, ...
- 大学生 从0开始学Spring第2篇：控制反转（IoC）与依赖注入【从0到精通】
控制反转(IoC)与依赖注 **引出spring** 依赖关系 spring 容器 IOC:控制反转 DI:依赖注入 总结 Spring中有3个核心的概念: 控制反转(Ioc). 依赖注入(DI). ...
- 浅谈spring之IoC控制反转
以下学习资料来源于b站动力节点 spring: 出现是在2002左右,解决企业开发的难度.减轻对项目模块之间的管理,类和类之间的管理, 帮助开发人员创建对象,管理对象之间的关系.spring核心技术 ...
- 为什么要使用Spring，为什么要使用控制反转（IOC）和依赖注入（DI），为什么要使用AOP
为什么要使用Spring,为什么要使用控制反转(IOC)和依赖注入(DI),为什么要使用AOP Spring是一个开源框架,Spring是于2003 年兴起的一个轻量级的Java 开发框架,由Rod ...
最新文章
- 3分钟内快速部署MySQL5.6.35数据库实践
- MariaDB/MySQL从数据库中选择随机的行
- java集合框架综述
- mysql min函数 结果全为null_MySQL ----- 聚集函数(AVG,SUM,COUNT,MIN,MAX) （十一）
- 一个可供中小团队参考的微服务架构技术栈
- Spring —— IoC 容器详解
- 通用寄存器：地址指针寄存器，数据寄存器，变址寄存器
- POJ1053 Set Me
- tampermonkey(油猴)跨域发送请求
- 0x00007FF872444FD9 处(位于 Project1.exe 中)有未经处理的异常: Microsoft C++ 异常: cv::Exception，位于内存位置 0x000000F11
- #STM32学习#6D加速度传感器测量风机震动
- Git 推送命令报错
- android mediastore参数,从 mediastore Android获取全屏幕缩略图
- Candence PCB Allegro④约束规则管理与布线
- 百度地图 ( 一 ) 显示地图
- 下一个时代的黑产攻防，可能没有人类什么事情了
- ERP系统有哪些品牌？
- 下载centos7.6光盘映像文件，使用VMware12创建虚拟机，设置固定IP，最全图文教程
- 网站被挂木马，中毒了
- css过滤镜实现颜色渐变