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有点像，但仔细思考后发现二者仍是有许多区别的。

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

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

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