Spring之IOC(学习笔记)

浅谈IOC

IOC理论的背景

依赖注入(DI)

IOC的好处

IOC的通俗理解

 

浅谈IOC

IOC(Inversionof Control,控制反转)是spring的核心，贯穿始终。所谓IOC，对于spring框架来说，就是由spring来负责控制对象的生命周期和对象的关系：

传统开发模式：对象之间相互依赖(如自己找女朋友)

IOC开发模式：IOC容器安排对象之间的依赖(如婚介，会按照要求给你提供)

 

所有的类都会在Spring容器中登记，告诉Spring"你"是什么，需要什么，Spring会在系统运行到适当时主动提供所需要的东西，同时把"你"交给需要你的东西，所有类的创建、销毁都由Spring来控制，也就是说控制对象生存周期的，不再是引用它的对象，而是Spring。对于某个具体的对象而言，以前是它控制其它对象，现在，是所有对象都被Spring控制，所以叫控制反转

 

IOC理论的背景

 

 

多个齿轮耦合在一起共同完成某项任务，如果有一个齿轮出现问题，就可能会影响整个系统的运转。齿轮组齿轮之间的耦合关系与软件系统中对象之间的耦合关系相似，对象之间的耦合关系是无法避免的,也是必要的，这是协同工作的基础。现在伴随着工业级规模越来越庞大，对象之间的依赖关系也越来越复杂，经常会出现对象之间的多重依赖关系，因此架构师和设计师对系统的分析和设计将面临着更大的挑战，对象之间耦合度过高的系统，必然会出现牵一发而动全身的情形，如何降低系统之间、模块之间和对象之间的耦合度是软件工程永远追求的目标之一，为了解决对象之间耦合度过高的问题，IOC被提出，用来实现对象之间的解耦

 

 

IOC的处理方式简单来说就是把复杂的系统分解成相互合作的对象，这些对象类通过封装以后内部实现对于外部是透明的，从而降低了解决问题的复杂度，而且可以被灵活的被重用和扩展；借助于第三方来实现对具有依赖关系对象关系之间的解耦(控制权上交给了第三方IOC容器,起到了类似粘合剂的作用，把系统中的所有对象粘合在一起发挥作用，这就是IOC容器被称作粘合剂的由来)

 

 

 

 

对象之间的依赖关系降低到了最低，参与开发的每个成员，只需要实现自己的类就行了

 

 

为什么叫控制反转

软件系统没有引入IOC容器之前，如图1 Object:A依赖于ObjectB, Object:A在进行初始化或运行到某一点时，自己必须生动地创建对象B,或者使用已经创建的Object:B，无论是创建还是使用Object:B，控制权依然在自己手中

引入IOC容器之后，如图2 Object：A和ObjectB失去了直接的联系，所以但运行到Object:A需要Object:B时IOC容器会主动地创建一个对象B注入到Object:A所需要的地方

不难看出，ObjectA获得依赖 ObjectB的过程由主动行为变成了被动行为，控制权颠倒了，这就是控制反转名称的由来。

 

依赖注入(DI)

 

IOC的另外的名字叫做注入依赖(Dependency Injection),所谓的注入依赖，就是由IOC容器在运行期间，动态地将某种依赖关系注入到对象之中。所以依赖注入(DI)和控制反转(IOC)是从不同角度的描述同一件事情，就是指通过引入IOC容器，利用依赖关系注入的方式，实现对象之间的解耦

 

IOC的好处

• IOC在编程过程中不会对业务对象构成很强的侵入性，使用IOC后，对象具有更好的可实行性、可重用性和可扩展性：
• 降低组件之间的耦合度
• 提高开发效率和产品质量
• 统一标准，提高模块的复用性
• 模块具有热插拔特性(当更换一个实现子类时，将会变得更加简单，只要修改配置文件就ok)

 

IOC的通俗理解

 

IOC控制反转：说的是创建对象实例的控制权从代码控制剥离到IOC容器控制，实际就是你在XML文件控制，侧重于原理

DI依赖注入：说的是创建对象实例时，为这个对象注入属性值或其他对象实例，侧重于实现