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

Posted 2020-07-07

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： 我不生产东西，本文所有内容都是从网上收集、整理、思考后的一个总结）