依赖倒置原则

依赖倒置原则的原始定义是：● 高层模块不应该依赖低层模块,两者都应该依赖其抽象;● 抽象不应该依赖细节;● 细节应该依赖抽象。那什么是抽象?什么又是细节呢?---->在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提供的一个规范。● 任何类都不应该从具体类派生        -->继承不得到超过两层。事无绝对。但可以追求完美。● 尽量不要覆写基类的方法        -->如果基类是一个抽象类,而且这个方法已经实现了,子类尽量不要覆写。类间依赖的是抽象,覆写了抽象方法,对依赖的稳定性会产生一定的影响。● 结合里氏替换原则使用