【Spring学习】IoC与DI

       看了两篇讲IoC和DI的文章，实在是讲得太好，有种不知道再怎么写的感觉，终于明白李白为啥说黄鹤楼景色虽好，却因崔颢的题诗在前，无法写诗是啥意思了。两篇文章见下：
       Spring的IOC原理[通俗解释一下]
       我对IoC/DI的理解

       不过，还是尽可能自己也总结一下，毕竟是别人的东西，记得不会太清楚。

1.概念

       IoC是Inversion of Control的缩写，字面意思：控制反转，这是一种设计思想，与技术可以无关。从概念上来解释，就是控制权转换，原先由下层对象控制依赖转换为由上层框架主动提供依赖。这样，只要框架提供一个统一的平台来进行依赖对象的管理，则下层对象就完全不需要在意依赖对象的创建，与其他对象的耦合也就降到了最低。
       DI是Dependency Injection的缩写，字面意思：依赖注入。这是后人因为IOC的含义不好理解，用于解释时给出的更贴切的一个词。这个词直接解释的是实现方式，依赖由外部框架注入到对象中，而不是对象主动生成。

2.好处

       解耦会带来什么好处呢？这与耦合度高的缺点是对应的。耦合度高，带来的问题就是『牵一发而动全身』，进而带来一系列问题：

1. 维护困难，往往改动一个模块，整个系统都需要进行调整；
2. 无法复用，模块间处处依赖，无法独立出模块进行复用；
3. 自由度低，难于替换实现；
4. 并行开发难，无法区分独立模块，也无法进行独立测试；

这些问题可以与第一篇文章中的USB的例子对应理解，通俗易懂。

3.技术

       使用IoC的容器框架有很多，Spring是其中的代表，也是Java开发中SSH(Struts、Spring、Hibernate)三剑客之一，非常成熟，使用简单，后续整理学习的也是这个框架。
       IoC容器使用的主要技术是JAVA的反射，利用反射可以方便的对类进行动态代理，进而控制类的生命周期，实现配置管理，可以说反射是大部分框架实现的基础。

4.注意

       第一篇文章中也指出了，小的项目引入Spring可能导致相当数量的配置，同时也需要对项目人员进行相关培训，利用反射的框架效率也会有一些损失。
       总之，需要在各方面进行权衡之后，才可以确定引入，而不是盲目乱用。

5.总结

       现在，计划图如下：