spring IOC/DI笔记

关于spring的IOC和DI，网络上有各种不同的文章可供阅读，但很多都是转载或者是“浅谈”，至少我看了好几篇被转的昏头昏脑。然后我直接看spring-framework-5文档，知道了给ioc和DI最早定义或者介绍的文章（至少我看到的是最早的了）

IoC容器和Dependency Injection模式 - Martin Fowler

讲解的十分透彻。这里我就做个随笔。

IOC和DI的区别

控制反转：将控制权反转（转交）给其他组件。

依赖注入：将接口的具体实现通过适配器或者容器注入给接口的调用方。

依赖注入实现的同时也达成了控制反转，因为它将对接口实现类的选择权交给了容器而不是主程序。所以Martin Fowler使用依赖注入来表示这个模式。

在我的理解中，依赖注入一定具有控制反转，但是控制反转不一定实现了依赖注入。 Martin Fowler也给出了例子：

在可视化页面的表单输入中，表单的校验如果从页面的代码进行校验交给校验组件。那么这就将校验的控制权反转给了组件或者框架。但是这个过程并没有实现依赖注入。

依赖注入与策略设计模式的思考

根据Martin Fowler的文章了解依赖注入的结构后发现它有点像策略设计模式。

策略设计模式：通过传入不同的参数来使用或者获取接口的不同实现

感觉和DI有点像，但仔细思考后发现两者还是有许多区别的。

首先是对接口的不同实现。策略设计的一个要求就是接口的不同实现都要在本地或者更加准确的说要在主程序中。但是随着项目越来越大业务功能越来越多，分工完成不同的业务实现是当前的主流。因此接口的实现就不一定在主程序中了。

而且如果用适配器来组合接口的不同实现和主程序，那么每次添加新的组件或者更换组件的时候都要在主程序中修改代码，这是十分麻烦的。

因此，使用一个通用的适配器或者说容器来管理所有的接口和对应的实现，如果要加入新的组件，只需要往容器中注册对应的接口类和它的实现。当主程序要使用或者扩展功能的时候只需要往容器中请求对应的接口就可以轻松的获取到该实现了。当第三方对这个组件有更加完善的实现的时候，只需要在容器中修改接口绑定的实现就可以轻松替换旧的组件。这种主程序-容器-组件完全分离的形式使得程序编写就像搭积木一样，通过获取不同的组件就能搭建出全新的应用功能。