参考《向依赖关系宣战》
依赖倒置，是把本来的直接依赖的关系，倒置为两者都对同一个抽象接口的依赖。从而实现被依赖方发生变化时，对依赖方产生最小的影响。
但是这样还是免不了要Reader a=new KeyboardReader(好处就是只要new一次KeyboardReader，之后用Reader这一接口就行了)，如果你想要一次KeyboardReader都不new，也就是不写死任何一个实现类，那就要使用依赖注入了。
相对依赖倒置这种构造方法上的概念，依赖注入只是一种技术实现，概念比较小，其实现方法有构造器注入，设值注入，接口注入等，以构造器注入为例，其实就是通过传参数的方式来导入KeyboardReader，不在库里面写死。
使用了依赖注入的依赖倒置，才能实现百分百的去除依赖。这也是那些框架里面需要我们去配置的XML文件。
控制反转，他指的是功能上的含义的变化。具体的例子就是回调函数，本来调用GUI框架时，需要在框架里面写好应该调用的应用程序的窗口函数。但使用回调函数的话，可以给GUI框架传一个指针，这样，就不用去更改框架里面的代码了。
其核心思想是，把本来是由应用程序控制整个流程；到由框架控制整个流程，应用程序只要调用一下框架就好了。
综上，依赖倒置就是抽象出接口。控制反转就是把流程交给框架。所以依赖倒置使用范围更加广、更加具体；控制反转只是一种概念，基本就用在框架中，其实现可以有很多种，可以用依赖倒置的抽象出接口的方式实现，也可以使用其他方式实现。
模板方法，是综合了依赖注入和控制反转的综合方法。
先使用依赖倒置，抽象出被依赖的接口给应用程序调用，然后再使用控制反转，抽象出接口给应用程序实现。
总地说来，应用程序和框架系统之间的依赖关系有以下特点：
1. 应用程序和框架系统之间实际上是双向调用，双向依赖的关系。
2. 依赖倒置原则可以减弱应用程序到框架之间的依赖关系。
3. “控制反转”及具体的模板方法模式可以消解框架到应用程序之间的依赖关系，这也是所有框
架系统的基础。
4. 框架系统可以独立重用。
####
#### 总结依赖倒置、控制反转、依赖注入、设计模式的关系。
分离接口和实现是人们有效地控制依赖关系的最初尝试，而纯粹的抽象接口更好地隔离了相互
依赖的两个模块，“依赖倒置”和 “控制反转”原则从不同的角度描述了利用抽象接口消解耦合的动机，
GoF 的设计模式正是这一动机的完美体现。具体类的创建过程是另一种常见的依赖关系，“依赖注
入”模式可以把具体类的创建过程集中到合适的位置，这一动机和 GoF 的创建型模式有相似之处。
