依赖倒置原则
依赖倒置原则的原始定义是：
● 高层模块不应该依赖低层模块,两者都应该依赖其抽象;
● 抽象不应该依赖细节;
● 细节应该依赖抽象。
那什么是抽象?什么又是细节呢?
---->在Java语言中,抽象就是指接口或抽象类,两者都是不能直接被实例化的;细节就是实现类,实现接口或继承抽象类而产生的类就是细节,其特点就是可以直接被实例化,也就是可以加上一个关键字new产生一个对象。依赖倒置原则在Java语言中的表现就是:
● 模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过
接口或抽象类产生的;
● 接口或抽象类不依赖于实现类;
● 实现类依赖接口或抽象类。更加精简的定义就是“面向接口编程”——OOD(Object-Oriented Design,面向对象设
计)的精髓之一。
依赖倒置的优点
---->减少类间的耦合性
---->提高系统的稳定性
---->降低并行开发引起的风险
---->提高代码的可读性和可维护性。
证明一个定理是否正确,有两种常用的方法:一种是根据提出的论题,经过一番论证,推出和定理相同的结论,这是顺推证法;还有一种是首先假设提出的命题是伪命题,然后推导出一个荒谬、与已知条件互斥的结论,这是反证法。我们今天就用反证法来证明依赖倒置原则是多么优秀和伟大
论题:依赖倒置原则可以减少类间的耦合性,提高系统的稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性。
反论题:不使用依赖倒置原则也可以减少类间的耦合性,提高系统的稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性。
Driver类
package com.yeepay.sxf.sj4;
/**
* 司机
* @author sxf
*
*/
public class Driver {
public void dirverCar(Benchi benchi){
System.out.println("Driver.dirverCar(人开车)");
benchi.run();
}
}
Car类
package com.yeepay.sxf.sj4;
/**
* 奔驰
* @author sxf
*
*/
public class Benchi {
public void run(){
System.out.println("Benchi.run(奔驰奔跑)");
}
}
Client类
public static void main(String[] args) {
Benchi vBenchi=new Benchi();
Driver diiDriver=new Driver();
diiDriver.dirverCar(vBenchi);
}
（1）如果人再想开宝马，则不灵活。耦合度大。抽象，面向接口编程，可以降低耦合度。
（2）大型项目。人分模块开发。高模块，不需要等待低模块开发完成，才能开发。只需要低模块的接口即可。
抽象是对实现的约束,对依赖者而言,也是一种契约,不仅仅约束自己,还同时约束自己与外部的关系,其目的是保证所有的细节不脱离契约的范畴,确保约束双方按照既定的契约(抽象)共同发展,只要抽象这根基线在,细节就脱离不了这个圈圈,始终让你的对象做到“言必信,行必果”。
依赖的三种写法
第一：构造函数传递依赖对象
第二：Setter方法传递依赖对象
第三：接口声明依赖对象
最佳实践
依赖倒置原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立,不互相影响,实现模块间的松耦合,我们怎么在项目中使用这个规则呢?只要遵循以下的几个规则就可以:
● 每个类尽量都有接口或抽象类,或者抽象类和接口两者都具备
-->这是依赖倒置的基本要求,接口和抽象类都是属于抽象的,有了抽象才可能依赖倒置。
● 变量的表面类型尽量是接口或者是抽象类
-->很多书上说变量的类型一定要是接口或者是抽象类,这个有点绝对化了,比如一个工具
类,xxxUtils一般是不需要接口或是抽象类的。还有,如果你要使用类的clone方法,就必须
使用实现类,这个是JDK提供的一个规范。
● 任何类都不应该从具体类派生
-->继承不得到超过两层。事无绝对。但可以追求完美。
● 尽量不要覆写基类的方法
-->如果基类是一个抽象类,而且这个方法已经实现了,子类尽量不要覆写。类间依赖的是抽象,覆写了抽象方法,对依赖的稳定性会产生一定的影响。
● 结合里氏替换原则使用