依赖倒置原则定义：
模块间的依赖通过抽象发生， 实现类之间不发生直接的依赖关系， 其依赖关系是通过接口或抽象类产生的 ,接口或抽象类不依赖于实现类,实现类依赖接口或抽象类。
依赖倒置原则的优点：
1.降低模块之间的耦合度，将每个类之间的依赖关系降到最低，相互依赖变少了，那么系统将会更加稳定。
2.有利于代码的扩展和维护，因为只用抽象来表示依赖关系，就可以使用该抽象类型的所有子类。
3.降低并行开发的风险，因为是面向接口编程，所以可以先定义抽象接口，然后多人同时开发，此时只要保证能正常调用接口，一般就不会出现问题。
依赖的三种写法：
1.构造函数传递依赖，该依赖的特点是依赖对象对于引用对象是必须的，并且他们的生命周期也是一致的，在创建引用对象的时候就需要传递依赖对象才能构造成功，并且依赖对象一般是不可变的，始终使用的是同一个。
2.set方法传递依赖，该依赖的特点是依赖对象和引用对象的生命周期一般不是同步的，也有可能不是必须的。可以在需要的时候注入依赖对象，也可以多次注入。
3.方法传递，这种传递方式对于引用对象的依赖程度最低，一般只有在调用该方法的时候才需要传递该依赖，其他情况下并不需要该依赖对象的支持。
学习心得：
依赖倒置原则的本质就是通过抽象（ 接口或抽象类） 使各个类或模块的实现彼此独立，
不互相影响， 实现模块间的松耦合， 我们怎么在项目中使用这个规则呢？ 只要遵循以下的几
个规则就可以：
1. 每个类尽量都有接口或抽象类， 或者抽象类和接口两者都具备
这是依赖倒置的基本要求， 接口和抽象类都是属于抽象的， 有了抽象才可能依赖倒置。
2. 变量的表面类型尽量是接口或者是抽象类
很多书上说变量的类型一定要是接口或者是抽象类， 这个有点绝对化了， 比如一个工具
类， xxxUtils一般是不需要接口或是抽象类的。 还有， 如果你要使用类的clone方法， 就必须
使用实现类， 这个是JDK提供的一个规范。
3.任何类都不应该从具体类派生
如果一个项目处于开发状态， 确实不应该有从具体类派生出子类的情况， 但这也不是绝
对的， 因为人都是会犯错误的， 有时设计缺陷是在所难免的， 因此只要不超过两层的继承都
是可以忍受的。 特别是负责项目维护的同志， 基本上可以不考虑这个规则， 为什么？ 维护工
作基本上都是进行扩展开发， 修复行为， 通过一个继承关系， 覆写一个方法就可以修正一个
很大的Bug， 何必去继承最高的基类呢？ （ 当然这种情况尽量发生在不甚了解父类或者无法
获得父类代码的情况下。 ）
4. 尽量不要覆写基类的方法
如果基类是一个抽象类， 而且这个方法已经实现了， 子类尽量不要覆写。 类间依赖的是
抽象， 覆写了抽象方法， 对依赖的稳定性会产生一定的影响。
5.结合里氏替换原则使用
根据里氏替换原则， 我们可以得出这样一个通俗的规则： 接口负责定义public属性和方法， 并且声明与其他
对象的依赖关系， 抽象类负责公共构造部分的实现， 实现类准确的实现业务逻辑， 同时在适当的时候对父类进行细化。