设计模式之禅之六大设计原则-依赖倒置原则

简介: 依赖倒置原则依赖倒置原则的原始定义是:● 高层模块不应该依赖低层模块,两者都应该依赖其抽象;● 抽象不应该依赖细节;● 细节应该依赖抽象。那什么是抽象?什么又是细节呢?---->在Java语言中,抽象就是指接口或抽象类,两者都是不能直接被实例化的;细节就是实现类,实现接口或继承抽象类而产生的类就是细节,其特点就是可以直接被实例化,也就是可以加上一个关键字new产生一个对象。

依赖倒置原则
依赖倒置原则的原始定义是:
● 高层模块不应该依赖低层模块,两者都应该依赖其抽象;
● 抽象不应该依赖细节;
● 细节应该依赖抽象。

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

相关文章
|
设计模式 关系型数据库
【设计模式——学习笔记】设计模式简介+七大设计原则介绍(下)
【设计模式——学习笔记】设计模式简介+七大设计原则介绍
128 0
|
6月前
|
设计模式
设计模式六大原则之依赖倒置原则
设计模式六大原则之依赖倒置原则
|
3月前
|
设计模式 Java 测试技术
Java设计模式-UML与设计原则(1)
Java设计模式-UML与设计原则(1)
|
4月前
|
设计模式 前端开发 JavaScript
React开发设计模式及原则概念问题之什么是HOC(Higher-order component),HOC遵循的设计原则都有哪些
React开发设计模式及原则概念问题之什么是HOC(Higher-order component),HOC遵循的设计原则都有哪些
|
5月前
|
设计模式 算法
交易链路设计原则&模式问题之中介者(Mediator)方法设计模式是什么,如何解决
交易链路设计原则&模式问题之中介者(Mediator)方法设计模式是什么,如何解决
|
7月前
|
设计模式 算法 Java
【设计模式系列笔记】设计模式与设计原则
设计模式,是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。 设计原则是一些通用的设计指导方针,它们提供了如何设计一个优秀的软件系统的基本思想和规则。指导着设计者如何组织代码以实现高内聚、低耦合、易扩展和易维护的软件系统。
90 4
|
7月前
|
设计模式 Java 数据安全/隐私保护
设计模式之六大设计原则
设计模式之六大设计原则
76 0
|
7月前
|
设计模式 关系型数据库 程序员
【设计模式】设计原则
【1月更文挑战第12天】【设计模式】设计原则
|
7月前
|
设计模式 Java
Java设计模式七大原则之依赖倒置原则
Java设计模式七大原则之依赖倒置原则
73 0
|
设计模式 程序员
设计模式-设计原则
设计模式-设计原则