IOC和DI

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

IOC 控制反转

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

简单例子介绍IOC的发展

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

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

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

红帽子：
这里写图片描述

黄帽子：
这里写图片描述

绿帽子(→_→)：
这里写图片描述

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

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

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

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

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

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

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

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