【Spring】IOC和DI

我就是我 2022-06-17 09:51 232阅读 0赞

# IOC和DI #

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

*  IOC和DI
    
     *  IOC 控制反转
        
         *  简单例子介绍IOC的发展
         *  到底什么被反转了
     *  DI 依赖注入
        
         *  构造注入
         *  设值注入

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

## IOC 控制反转 ##

应用程序不再负责依赖对象的创建和维护，而是由外部容器负责创建和维护。

### 简单例子介绍IOC的发展 ###

举一个例子：  
在很远的X星球上有一种人，每个人都有一顶有颜色的帽子。  
![这里写图片描述][SouthEast]

先定义一个Hat接口，里面有个方法可以打印出帽子的颜色。  
![这里写图片描述][SouthEast 1]

刚开始呢，因为X星球的科学技术并不发达，只能生产三种颜色，红、绿、黄。所以开始的时候只有3种帽子。

红帽子：  
![这里写图片描述][SouthEast 2]

黄帽子：  
![这里写图片描述][SouthEast 3]

绿帽子(→\_→)：  
![这里写图片描述][SouthEast 4]

接下来我们来造个人吧。先造个老王，老王要出来首先要有个帽子，他喜欢红色，就new了一个红帽子，接着造一个老李，这时候老王把黄帽子都藏起来了，没办法，老李new了个绿帽子。  
![这里写图片描述][SouthEast 5]

这样看起来好像没有问题，X星球的人就这样出生然后new一个帽子，但是随着时间的流逝，星球的科技也逐步发展壮大，可以产出很多色彩了，因为帽子对他们很重要，所以帽子的种类颜色也多了。之前的帽子不fashion了，也产生了更换帽子的方法。之前的这种方式，就是老王出生的时候，需要自己去new个红帽子（调用红帽子的构造方法），想换黄帽子的时候，也要自己new一个，这个就相当于老王知道自己怎么出生（自己的构造方法），还要知道某个帽子的制作方法（红帽子的构造方法）， 而帽子的种类越来越多，new的选择也越来越多，老王就要掌握很多很多种帽子的制作方法，这就很麻烦啊，不只是老王，全星球的人都有这个困扰。  
![这里写图片描述][SouthEast 6]

如果继续这么下去，大家都会因为帽子而变得很乱啊，上图中帽子的实现类越来越多，和person的关系也会变得复杂。  
聪明的统治者想出一个办法，就是建造一间帽子工厂HatFactory，把制作帽子的活交给工厂的工人去干。  
![这里写图片描述][SouthEast 7]

人民不需要知道帽子的制作过程，只要知道自己想要什么颜色的帽子就好。  
![这里写图片描述][SouthEast 8]

只需要告诉工厂想要什么颜色的帽子，而不需要去关心，这个帽子的制作过程，这一切繁琐的过程都交给了工厂去做。这时候person与各种帽子间的关系就变成了这样。  
![这里写图片描述][SouthEast 9]

从图上可以看出来，如果帽子的种类再增加或者减少的时候，person并不需要关心，这是工厂干的活。  
大家都觉得这种方式不错，慢慢的星球上出现了一些特别聪明的人，他们觉得工厂还是很麻烦，于是他们想出用机器人去自动管理帽子，当人们需要一个帽子的时候，机器人会自动给你分配你想要的一个帽子，你只要用语言提前告诉机器人，怎么去管理就好。  
![这里写图片描述][SouthEast 10]

这时候person和各种帽子之间的关系就变成了这样。  
![这里写图片描述][SouthEast 11]  
其实这里隐藏了一条线，就是IOC容器，就是Spring，把工作都交给容器去做，我们并没有去new任何的person或者是帽子，只需要获得容器，从容器中获取帽子。  
![这里写图片描述][SouthEast 12]

上面举了一个或许不恰当的例子来介绍IOC的发展历程。  
首先就是当person需要一个hat对象的时候，这时候就产生了依赖关系，各种帽子就是person的依赖对象，刚开始的时候，person需要依赖对象的时候，需要自己去new一个对象，这时候person和依赖对象的耦合度是最高的，在依赖对象类型多的时候，person来管理就变得很麻烦，所以后来就产生了工厂，采用工厂设计模式，把依赖对象的创建过程交给工厂去管理，我们只需要管理一个工厂就好，这时候person和依赖对象的耦合程度就降低了，后来又产生了使用IOC容器去管理我们的依赖对象，这时候在我们的代码不会看到new依赖对象，只需要配置文件就好，通过IOC达到松耦合的目的，让Spring管理应用对象的配置和生命周期，而我们不需要去new对象。

### 到底什么被反转了 ###

从上面的例子看出，我们一直在降低依赖对象的耦合度，从自己创建依赖对象，到把依赖对象的创建工作交给工厂去做，到最后把所有对象的创建和管理交给了容器去做，这就是反转的过程。**是获得依赖对象的过程被反转了，获得依赖对象的过程由程序自身管理变成了由IOC容器主动注入。**

## DI 依赖注入 ##

依赖注入可以说是IOC的一种实现方式，主要有2种注入方式。

### 构造注入 ###

就是通过构造方法把依赖对象传入，在Spring配置文件这么写就好。  
![这里写图片描述][SouthEast 13]

### 设值注入 ###

设值注入就是通过setter方法把依赖的对象传入，在Spring中做如下配置即可。  
![这里写图片描述][SouthEast 14]

[SouthEast]: /images/20220617/eb08b26c49ef43ce8c01e9c9d609d00f.png
[SouthEast 1]: /images/20220617/5010c771ba604df39bbfaddfca832110.png
[SouthEast 2]: /images/20220617/d75805cf7fe641b3a4f5607bff2a1784.png
[SouthEast 3]: /images/20220617/949fa4a90fc842fc84e49302379b321f.png
[SouthEast 4]: /images/20220617/a6c92f2e3ed04942b051955851732164.png
[SouthEast 5]: /images/20220617/cc4dea82b2c34e7786d14a5f7b354fc1.png
[SouthEast 6]: /images/20220617/242925dd86e74ebab7cba0ef574b5613.png
[SouthEast 7]: /images/20220617/4ea6e2d17d294f11a6e85670ce0f2617.png
[SouthEast 8]: /images/20220617/d5b1bd43bf554147952b17cac2eacdc1.png
[SouthEast 9]: /images/20220617/93bd65191f35446c9fd9643ec1f963f1.png
[SouthEast 10]: /images/20220617/4454cca576204ace8f01d84eda1c2dae.png
[SouthEast 11]: /images/20220617/770639ca56774751b8c39797ecf9dae4.png
[SouthEast 12]: /images/20220617/8670378215fe40e89894c783aff9f2cb.png
[SouthEast 13]: /images/20220617/364e3cde587c47d7a0c43d6b0358eb14.png
[SouthEast 14]: /images/20220617/e6b92aaadfcd460daf3810293c2ff605.png