Spring---IOC简介

最新推荐文章于 2024-08-04 23:32:31 发布

HLA_胡

最新推荐文章于 2024-08-04 23:32:31 发布

阅读量2.7k

点赞数

分类专栏：框架文章标签： spring IOC DI

本文链接：https://blog.csdn.net/hla199106/article/details/47614527

版权

框架专栏收录该内容

13 篇文章 0 订阅

订阅专栏

本文介绍了Spring中的控制反转(IoC)和依赖注入(DI)概念，阐述了IoC容器如何实现对象的被动实例化和依赖装配，强调了其在降低耦合和提高代码可测试性上的作用。通过对IoC和DI的对比和实例解释，揭示了它们在面向对象设计中的重要性，以及在实际应用中如何帮助构建松散耦合的系统。

摘要由CSDN通过智能技术生成

1、引言

1.1 为什么需要IoC容器

(1)应用程序主动控制对象的实例化及依赖装配

A a = new AImpl();  
B b = new BImpl();  
a.setB(b);

本质：创建对象，主动实例化，直接获取依赖，主动装配
缺点：更换实现需要重新编译源代码
很难更换实现、难于测试
耦合实例生产者和实例消费者

A a = AFactory.createA();  
B b = BFactory.createB();  
a.setB(b)

本质：创建对象，被动实例化，间接获取依赖，主动装配（简单工厂）
缺点：更换实现需要重新编译源代码
很难更换实现、难于测试

A a = Factory.create(“a”);  
B b = Factory.create(“b”);  
a.setB(b); 

<!—配置.properties-->
a=AImpl  
b=BImpl

本质：创建对象，被动实例化，间接获取依赖，主动装配
（工厂+反射+properties配置文件、Service Locator、注册表）
缺点：冗余的依赖装配逻辑

(2)可配置通用工厂：工厂主动控制，应用程序被动接受，控制权从应用程序转移到工厂

//返回装配好的a   
A a = Factory.create(“a”);

<!—配置文件-->
<bean id=“a” class=“AImpl”>  
    <property name=“b” ref=“b”/>  
</bean>  
<bean id=“b” class=“BImpl”/>

本质：创建对象和装配对象，
被动实例化，被动接受依赖，被动装配
（工厂+反射+xml配置文件）
缺点：不通用

步骤：
1、读取配置文件根据配置文件通过反射创建AImpl
2、发现A需要一个类型为B的属性b
3、到工厂中找名为b的对象，发现没有，读取配置文件通过反射创建BImpl
4、将b对象装配到a对象的b属性上
【组件的配置与使用分离开（解耦、更改实现无需修改源代码、易于更好实现）】

(3)IoC(控制反转)容器：容器主动控制

//返回装配好的a   
A a = ApplicationContext.getBean(“a”);  

<!—配置文件-->
<bean id=“a” class=“AImpl”>  
    <property name=“b” ref=“b”/>  
</bean>  
<bean id=“b” class=“BImpl”/>

本质：创建对象和装配对象、管理对象生命周期
被动实例化，被动接受依赖，被动装配
（工厂+反射+xml配置文件）

通用

IoC容器：实现了IoC思想的容器就是IoC容器

IoC容器特点：

【1】无需主动new对象；而是描述对象应该如何被创建即可IoC容器帮你创建，即被动实例化；

【2】不需要主动装配对象之间的依赖关系，而是描述需要哪个服务（组件），IoC容器会帮你装配（即负责将它们关联在一起），被动接受装配；

【3】主动变被动，好莱坞法则：别打电话给我们，我们会打给你；

【4】迪米特法则（最少知识原则）：不知道依赖的具体实现，只知道需要提供某类服务的对象（面向抽象编程），松散耦合，一个对象应当对其他对象有尽可能少的了解,不和陌生人（实现）说话。

【5】IoC是一种让服务消费者不直接依赖于服务提供者的组件设计方式，是一种减少类与类之间依赖的设计原则。

2、什么是IOC

Ioc—Inversion of Control，即“控制反转”，不是什么技术，而是一种设计思想。在Java开发中，Ioc意味着将你设计好的对象交给容器控制，而不是传统的在你的对象内部直接控制。

2.1 如何理解好Ioc呢？

理解好Ioc的关键是要明确“谁控制谁，控制什么，为何是反转（有反转就应该有正转了），哪些方面反转了”：

2.1.1 谁控制谁?

传统Java SE程序设计，我们直接在对象内部通过new进行创建对象，是程序主动去创建依赖对象；

而IoC是有专门一个容器来创建这些对象，即由Ioc容器来控制对象的创建；

2.1.2 控制什么？

那就是主要控制了外部资源获取（不只是对象包括比如文件等）。

2.1.3 为何是反转？

有反转就有正转，传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象，也就是正转；

而反转则是由容器来帮忙创建及注入依赖对象；为何是反转？因为由容器帮我们查找及注入依赖对象，对象只是被动的接受依赖对象，所以是反转；

2.1.4 哪些方面反转了？

依赖对象的获取被反转了。即是对象的控制权发生了反转：从应用程序转移到了IoC容器。

用图例说明一下，传统程序设计如下图，都是主动去创建相关对象然后再组合起来：

当有了IoC/DI的容器后，在客户端类中不再主动去创建这些对象了如图所示:

2.2 IoC能做什么

IoC不是一种技术，只是一种思想，一个重要的面向对象编程的法则，它能指导我们如何设计出松耦合、更优良的程序。传统应用程序都是由我们在类内部主动创建依赖对象，从而导致类与类之间高耦合，难于测试；有了IoC容器后，把创建和查找依赖对象的控制权交给了容器，由容器进行注入组合对象，所以对象与对象之间是松散耦合，这样也方便测试，利于功能复用，更重要的是使得程序的整个体系结构变得非常灵活。
其实IoC对编程带来的最大改变不是从代码上，而是从思想上，发生了“主从换位”的变化。应用程序原本是老大，要获取什么资源都是主动出击，但是在IoC/DI思想中，应用程序就变成被动的了，被动的等待IoC容器来创建并注入它所需要的资源了。
IoC很好的体现了面向对象设计法则之一—— 好莱坞法则：“别找我们，我们找你”；即由IoC容器帮对象找相应的依赖对象并注入，而不是由对象主动去找。

IoC容器功能：实例化、初始化组件、装配组件依赖关系、负责组件生命周期管理。

3、什么是DI

DI：依赖注入（Dependency Injection）：用一个单独的对象（装配器）来装配对象之间的依赖关系。

3.1 理解DI问题关键

谁依赖于谁？ ------- 应用程序依赖于IoC容器

为什么需要依赖？ ------- 应用程序需要IoC容器来提供对象需要的外部资源；

依赖什么东西？ ------- 依赖了IoC容器的装配功能

谁注入于谁？ ------- IoC容器注入应用程序某个对象，应用程序依赖的对象

注入什么东西？ ------- 注入应用程序需要的资源（包括对象、资源、常量数据、类之间的关系）

更能描述容器其特点的名字——“依赖注入”（Dependency Injection）IoC容器应该具有依赖注入功能，因此也可以叫DI容器

3.2 DI优点

【1】帮你看清组件之间的依赖关系，只需要观察依赖注入的机制（setter/构造器），就可以掌握整个依赖（类与类之间的关系）。

【2】组件之间的依赖关系由容器在运行期决定，形象的来说，即由容器动态的将某种依赖关系注入到组件之中。

【3】依赖注入的目标并非为软件系统带来更多的功能，而是为了提升组件重用的概率，并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定目标需要的资源，完成自身的业务逻辑，而不用关心具体的资源来自何处、由谁实现。

使用DI限制：组件和装配器（IoC容器）之间不会有依赖关系，因此组件无法从装配器那里获得更多服务，只能获得配置信息中所提供的那些。

4、IoC和DI由什么关系呢？

其实它们是同一个概念的不同角度描述，由于控制反转概念比较含糊（可能只是理解为容器控制对象这一个层面，很难让人想到谁来维护对象关系），所以2004年大师级人物Martin Fowler又给出了一个新的名字：“依赖注入”，相对IoC 而言，“依赖注入”明确描述了“被注入对象依赖IoC容器配置依赖对象”。

本质：
IoC：控制权的转移，由应用程序转移到框架；
IoC/DI容器：由应用程序主动实例化对象变被动等待对象（被动实例化）；
DI：由专门的装配器装配组件之间的关系；
IoC/DI容器：由应用程序主动装配对象的依赖变应用程序被动接受依赖

5、实例

ioc的思想最核心的地方在于，资源不由使用资源的双方管理，而由不使用资源的第三方管理，这可以带来很多好处。

第一，资源集中管理，实现资源的可配置和易管理。

第二，降低了使用资源双方的依赖程度，也就是我们说的耦合度。

也就是说，甲方要达成某种目的不需要直接依赖乙方，它只需要达到的目的告诉第三方机构就可以了，比如甲方需要一双袜子，而乙方它卖一双袜子，它要把袜子卖出去，并不需要自己去直接找到一个卖家来完成袜子的卖出。它也只需要找第三方，告诉别人我要卖一双袜子。这下好了，甲乙双方进行交易活动，都不需要自己直接去找卖家，相当于程序内部开放接口，卖家由第三方作为参数传入。甲乙互相不依赖，而且只有在进行交易活动的时候，甲才和乙产生联系。反之亦然。这样做什么好处么呢，甲乙可以在对方不真实存在的情况下独立存在，而且保证不交易时候无联系，想交易的时候可以很容易的产生联系。甲乙交易活动不需要双方见面，避免了双方的互不信任造成交易失败的问题。因为交易由第三方来负责联系，而且甲乙都认为第三方可靠。那么交易就能很可靠很灵活的产生和进行了。

这就是ioc的核心思想。生活中这种例子比比皆是，支付宝在整个淘宝体系里就是庞大的ioc容器，交易双方之外的第三方，提供可靠性可依赖可灵活变更交易方的资源管理中心。另外人事代理也是，雇佣机构和个人之外的第三方。

在以上的描述中，诞生了两个专业词汇，依赖注入和控制反转

所谓的控制反转，甲乙双方不相互依赖，交易活动的进行不依赖于甲乙任何一方，整个活动的进行由第三方负责管理。

所谓的依赖注入，则是，甲方开放接口，在它需要的时候，能够将乙方传递进来(注入)

参考来源：

我对IoC/DI的理解

【第二章】 IoC 之 2.1 IoC基础 ——跟我学Spring3