Spring -- IOC/DI 基础概念的理解

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Spring -- IOC/DI 基础概念的理解相关的知识,希望对你有一定的参考价值。

Spring -- IOC/DI 基础概念

思维导图:

 技术分享

-------------------------------------------------------

IoC/DI 的基本概念

 IoC是什么 ?

  IoC -- Inversion of control, 控制反转

     在Java开发中,IoC意味着将你设计好的对象交给容器控制,而不是传统的在你的对象内部直接控制。IoC是一种让服务消费者不直接依赖于服务提供者的组件设计方式,是一种减少类与类之间依赖的设计原则.

   理解IoC的关键是明确"谁控制谁,控制什么,为何是反转,哪些方面反转了",下面来深入分析一下:

   谁控制谁,控制了什么: 传统Java SE程序设计,我们直接在对象内部通过new进行创建对象,是程序主动去创建以来对象; 而IoC是有专门的一个容器来创建这些对象,即由IoC容器来控制对象的创建; 控制什么 ---> 主要控制了外部资源的获取

   为何是反转,哪些方面反转了: 有反转就有正转,传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象,也就是正转; 而反转则是由容器来帮忙创建及注入依赖对象;  为何是反转? ---> 因为由容器帮我们查找及注入依赖对象,对象只是被动的接受依赖对象,所以是反转;   哪些方面反转了?  ---> 依赖对象的获取被反转了.

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

   技术分享 

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

    技术分享

 

  IoC能干什么?

    IoC不是一种技术,只是一种思想,一个重要的面向对象编程的法则,它能指导我们如何设计出松耦合、更优良的程序。传统应用程序都是由我们在类内部主动创建依赖对象,从而导致类与类之间高耦合,难于测试; 有了IoC容器后, 把创建对象和查找依赖对象的控制权交给了容器, 由容器进行注入组合对象, 所以对象与对象之间是松散耦合, 这样也方便测试, 利于功能复用,更重要的是使得程序的整个体系结构变得非常灵活. 

    其实,IoC对编程带来的最大改变不是从代码上,而是从思想上,发生了"主从换位"的变化,应用程序原本是老大,要获取什么资源都是主动出击,但是在IoC/DI思想中,应用程序就变成被动的了,被动的等待IoC容器来创建并注入它所需要的资源了.

  DI是什么?

    DI -- Dependency Injection,依赖注入

      即组件之间的依赖关系由容器在运行期决定,形象的来说,即由容器动态的将某种依赖关系注入到组件之中依赖注入的目标并非为软件系统带来更多的功能,而是为了提升组件重用的概率,并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制,我们只需要通过简单的配置,而无需任何代码就可指定目标需要的资源,完成自身的业务逻辑,而不用关心具体的资源来自何处、由谁实现.

    理解DI的关键是 "谁依赖谁,为什么需要依赖, 谁注入谁,注入了什么",下面来深入分析一下:

    谁依赖于谁 :  应用程序依赖于IoC/DI容器

    为什么需要依赖 : 因为反转后,应用程序所依赖都资源都在IoC/DI容器中

    谁注入谁 : IoC/DI容器注入应用程序

    注入了什么: 注入了应用程序需要的外部资源,比如:依赖关系

  

  控制反转和依赖注入之间是同一个概念吗?

    它们不是同一个概念,但是它们是同一个概念的不同角度的描述。

    控制反转(IoC)从 IoC容器的角度来说

    依赖注入(DI) 从应用程序的角度来说      

  

  何为外部资源?

    对于一个类来说,所谓外部资源,就是指在自己类的内部不能得到或实现的东西。

      比如,在类里面要读取一个配置文件,那么,这个配置文件就相当于这个类的外部资源

      比如,A类里面要调用B类,那么对于A类来说B类就是外部资源  

------------------------------------------------------------------- 

IoC/DI基本的思想演变

 (1)Java基础阶段

    技术分享

  在C类里面需要使用接口A,最原始的写法是:

    A a = new A1(); 或者 A a = new A2();  然后通过a来调用接口的方法,对于C来说是主动实例化对象,直接获取依赖.

  上面这种实现方法的缺点:

    a、更换实现需要重新编译源代码

    b、很难更换实现,很难测试

    c、耦合实例生产者和实例消费者

 (2)Factory阶段

  技术分享

  使用工厂模式 -- Factory,在C类里面需要使用接口A,应用工厂模式的写法是:

    A a = Factory.createA();   然后通过a来调用接口的方法,这样的话对于C来说是被动实例化对象,间接获取依赖,但对于工厂类来说是主动实例化对象、获取依赖

  上述实现方式有何缺点:

    1、只是将阶段1中 实例化对象、获取依赖 放入到了工厂中,但是主动的问题还是存在

    2、更换实现需要重新编译源代码

    3、很难更换实现、难于测试

 (3)Factory+xml+反射 阶段

  技术分享

  继续进化到使用工厂模式加配置文件 --- Factory + xml +反射

  在C类里面需要使用接口A,应用工厂模式的写法是:

    A a = Factory.createA(); 然后通过a来调用接口的方法。在工厂类里面使用配置文件来决定要实例化的具体类。对于C类说是被动创建对象,间接获取依赖,对于工厂来说也是被动的

   上述实现方式的缺点:

    1、如何实例化带参数的类

    2、如何在对调用方法的传递值

 (4)IoC/DI阶段

  技术分享

  继续进化,就到了IoC/DI的层次了,在这种设计里面,出现了IoC/DI容器,容器对IoC/DI涉及的元素进行整体控制,并提供更多更好的通用服务。

  此时在C类里面需要使用接口A,以Sprin为列:

    A a = BeanFactory.getBean("XXX");  然后通过a来调用接口的方法

  此时由IoC/DI容器来创建对象和装配对象,并管理对象生命周期。对于应用程序而言,就是被动实例化和被动接受依赖了。

 

-------------------------------------------------------------------

IoC/DI容器的概念和Bean的概念

  Ioc/DI的基本思想

    1、把程序之间的依赖关系去掉

    2、把程序对象设置到IoC/DI容器的配置中,作为Bean来统一管理

    3、由IoC/DI容器来管理Bean的创建、实例化

    4、由IoC/DI容器来把Bean之间的关系注入到需要这些关系的对象里面

  简而言之:就是把对象之间的依赖关系全部去掉,由IoC/DI容器来管理对象和对象之间的依赖关系,实现对象之间的松散耦合.

  IoC容器: 简单的理解就是,实现IoC思想,并提供对象创建、对象装配以及对象生命周期管理的软件就是IoC容器

  IoC理解:

    1、应用程序无需主动new对象;而是描述对象应该如何被创建即可,IoC容器帮你创建,即被动实例化;

    2、应用程序不需要主动装配对象之间的依赖关系,而是描述需要哪个服务,IoC容器会帮你装配,被动接受装配;

     3、主动变被动,以前创建对象、装配对象的依赖关系都是由应用程序主动完成,现在变成被动了由IoC容器来完成;

    4、应用程序不知道依赖的具体实现,只知道需要提供某类服务的对象,达到并松散耦合;

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

 

  使用Ioc/DI容器开发需要改变思路

    1、应用程序不主动创建对象,但是要描述创建它们的方法

    2、在应用程序代码中不直接进行服务的装配,但是要描述哪一个组件需要哪一项服务,由容器负责将这些装配在一起

    也就是说:所有的组件都是被动的,组件初始化和装配都由容器负责,应用程序只是获取相应的组件后,实现应用的功能即可.

    (PS: IoC/DI是思想,不是纯实现技术。IoC是框架共性,只是控制权的转移到了框架,所以不能因为实现了IoC就叫IoC容器,而一般除了实现了IoC外,还具有DI功能的才叫IoC容器,因为容器除了要负责创建并装配组件关系,还需要管理组件的生命周期)

--------------------------------------------------------------------------

(PS: 我不生产东西,本文所有内容都是从网上收集、整理、思考后的一个总结) 

 

 

以上是关于Spring -- IOC/DI 基础概念的理解的主要内容,如果未能解决你的问题,请参考以下文章

spring ioc Di

对IoC和DI的理解

基础概念

依赖注入(DI)和控制反转(IOC)

如何理解Spring IOC

Spring IOC的理解