Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!

1 定义

Dependence Inversion Principle,DIP
High level modules should not depend upon low level modules.Both should depend upon abstractions.高层模块不应该依赖低层模块,二者都应该依赖其抽象
Abstractions should not depend upon details.Details should depend upon abstractions.抽象不应该依赖细节;细节应该依赖抽象

针对接口编程,不要针对实现编程。

每个逻辑的实现都是由原子逻辑组成的,不可分割的原子逻辑就是低层模块,原子逻辑的再组装就是高层模块
在Java语言中,抽象就是指接口或抽象类,两者都是不能直接被实例化的
细节就是实现类,实现接口或继承抽象类而产生的类就是细节,其特点就是可以直接被实例化,也就是可以加上一个关键字new产生一个对象。
依赖倒置原则在Java语言中的表现就是:
● 模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生的;
● 接口或抽象类不依赖于实现类;
● 实现类依赖接口或抽象类。

优点:可以减少类间的耦合性、提高系统稳定性,提高代码可读性和可维护性,可降低修改程序所造成的风险。

能不能把依赖弄对,要动点脑。依赖关系没处理好,就会导致一个小改动影响一大片。
把依赖方向搞反,就是最典型错误。

最重要的是要理解“倒置”,而要理解什么是“倒置”,就要先理解所谓的“正常依赖”是什么样的。
结构化编程思路是自上而下功能分解,这思路很自然地就会延续到很多人的编程习惯。按照分解结果,进行组合。所以,很自然地写出下面这种代码
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》
这种结构天然的问题:高层模块依赖于低层模块:

  • CriticalFeature是高层类
  • Step1和Step2就是低层模块,而且Step1和Step2通常都是具体类

很多人好奇了:step1和step2如果是接口,还有问题吗?像这种流程式的代码还挺常见的?
有问题,你无法确定真的是Step1和Step2,还会不会有Step3,所以这个设计依旧是不好的。如果你的设计是多个Step,这也许是个更好的设计。

在实际项目中,代码经常会直接耦合在具体的实现上。比如,我们用Kafka做消息传递,就在代码里直接创建了一个KafkaProducer去发送消息。我们就可能会写出这样的代码:
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》
我用Kafka发消息,创建个KafkaProducer,有什么问题吗?
我们需要站在长期角度去看,什么东西是变的、什么东西是不变的。Kafka虽然很好,但它并不是系统最核心部分,未来是可能被换掉的。

你可能想,这可是我的关键组件,怎么可能会换掉它?
软件设计需要关注长期、放眼长期,所有那些不在自己掌控之内的东西,都有可能被替换。替换一个中间件是经常发生的。所以,依赖于一个可能会变的东西,从设计的角度看,并不是一个好的做法。

那该怎么做呢?这就轮到倒置了。

倒置,就是把这种习惯性的做法倒过来,让高层模块不再依赖低层模块。
功能该如何完成?

计算机科学中的所有问题都可以通过引入一个间接层得到解决。 All problems in computer science can be
solved by another level of indirection —— David Wheeler

引入一个间接层,即DIP里的抽象,软件设计中也叫模型。这段代码缺少了一个模型,而这个模型就是这个低层模块在这个过程中所承担角色。

2 实战

重构

既然这个模块扮演的就是消息发送者的角色,那我们就可以引入一个消息发送者(MessageSender)的模型:
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》
有了消息发送者这个模型,又该如何把Kafka和这个模型结合呢?
实现一个Kafka的消息发送者:
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》
这样高层模块就不像之前直接依赖低层模块,而是将依赖关系“倒置”,让低层模块去依赖由高层定义好的接口。
好处就是解耦高层模块和低层实现。

若日后替换Kafka,只需重写一个MessageSender,其他部分无需修改。这就能让高层模块保持稳定,不会随低层代码改变。

这就是建立模型(抽象)的意义。

所有软件设计原则都在强调尽可能分离变的部分和不变的部分,让不变的部分保持稳定。
模型都是相对稳定的,而实现细节是易变的。所以,构建稳定的模型层是关键。

依赖于抽象

抽象不应依赖于细节,细节应依赖于抽象。

简单理解:依赖于抽象,可推出具体编码指导:

  • 任何变量都不应该指向一个具体类
    如最常用的List声明《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》

  • 任何类都不应继承自具体类

  • 任何方法都不应该改写父类中已经实现的方法

当然了,如上指导并非绝对。若一个类特稳定,也可直接用,比如String 类,但这种情况很少!
因为大多数人写的代码稳定度都没人家 String 类设计的高。

学习

首先定义一个学习者类
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》
简单的测试类
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》
假如现在又想学习Python,则面向实现编程就是直接在类添加方法
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》
此类需经常改变,扩展性太差,Test 高层模块, Learner 类为低层模块,耦合度过高!

让我们引入抽象:
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》

现在就能将原学习者类的方法都消除
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》

3 证明

采用依赖倒置原则可减少类间耦合,提高系统稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性。

证明一个定理是否正确,有两种常用方法:

  • 顺推证法
    根据论题,经过论证,推出和定理相同结论
  • 反证法
    先假设提出的命题是伪命题,然后推导出一个与已知条件互斥结论

反证法来证明依赖倒置原则的优秀!

论题

依赖倒置原则可减少类间的耦合性,提高系统稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性。

反论题

不使用依赖倒置原则也可减少类间的耦合性,提高系统稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性。

通过一个例子来说明反论题不成立!

  • 司机驾驶奔驰车类图
    《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》

奔驰车可提供一个方法run,代表车辆运行:
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》

司机通过调用奔驰车的run方法开动奔驰车
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》

有车,有司机,在Client场景类产生相应的对象
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》

现在来了新需求:张三司机不仅要开奔驰车,还要开宝马车,又该怎么实现呢?
走一步是一步,先把宝马车产生出来
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》
宝马车产生了,但却没有办法让张三开起来,为什么?
张三没有开动宝马车的方法呀!一个拿有C驾照的司机竟然只能开奔驰车而不能开宝马车,这也太不合理了!在现实世界都不允许存在这种情况,何况程序还是对现实世界的抽象。

我们的设计出现了问题:司机类和奔驰车类紧耦合,导致系统可维护性大大降低,可读性降低
两个相似的类需要阅读两个文件,你乐意吗?还有稳定性,什么是稳定性?固化的、健壮的才是稳定的,这里只是增加了一个车类就需要修改司机类,这不是稳定性,这是易变性。
被依赖者的变更竟然让依赖者来承担修改成本,这样的依赖关系谁肯承担?
证明至此,反论题已经部分不成立了。

继续证明,“减少并行开发引起的风险”

什么是并行开发的风险?

并行开发最大的风险就是风险扩散,本来只是一段程序的异常,逐步波及一个功能甚至模块到整个项目。一个团队,一二十个开发人员,各人负责不同功能模块,甲负责汽车类的建造,乙负责司机类的建造,在甲没有完成的情况下,乙是不能完全地编写代码的,缺少汽车类,编译器根本就不会让你通过!在缺少Benz类的情况下,Driver类能编译吗?更不要说是单元测试了!在这种不使用依赖倒置原则的环境中,所有开发工作都是“单线程”,甲做完,乙再做,然后是丙继续……这在20世纪90年代“个人英雄主义”编程模式中还是比较适用的,一个人完成所有的代码工作。但在现在的大中型项目中已经是完全不能胜任了,一个项目是一个团队协作的结果,一个“英雄”再牛也不可能了解所有的业务和所有的技术,要协作就要并行开发,要并行开发就要解决模块之间的项目依赖关系,那然后呢?
依赖倒置原则隆重出场!

根据以上证明,若不使用依赖倒置原则就会加重类间的耦合性,降低系统的稳定性,增加并行开发引起的风险,降低代码的可读性和可维护性。

引入DIP后的UML:
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》
建立两个接口:IDriver和ICar,分别定义了司机和汽车的各个职能,司机就是驾驶汽车,必须实现drive()方法
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》
接口只是一个抽象化的概念,是对一类事物的最抽象描述,具体的实现代码由相应的实现类来完成
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》
IDriver通过传入ICar接口实现了抽象之间的依赖关系,Driver实现类也传入了ICar接口,至于到底是哪个型号的Car,需要声明在高层模块。

ICar及其两个实现类的实现过程:
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》

业务场景应贯彻“抽象不应依赖细节”,即抽象(ICar接口)不依赖BMW和Benz两个实现类(细节),因此在高层次的模块中应用都是抽象:
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》

Client属于高层业务逻辑,它对低层模块的依赖都建立在抽象上,java的表面类型是IDriver,Benz的表面类型是ICar。

在这个高层模块中也调用到了低层模块,比如new Driver()和new Benz()等,如何解释?

java的表面类型是IDriver,是一个接口,是抽象的、非实体化的,在其后的所有操作中,java都是以IDriver类型进行操作,屏蔽了细节对抽象的影响。当然,java如果要开宝马车,也很容易,只需修改业务场景类即可。

在新增加低层模块时,只修改了业务场景类,也就是高层模块,对其他低层模块如Driver类不需要做任何修改,业务就可以运行,把“变更”引起的风险扩散降到最低。

Java只要定义变量就必然要有类型,一个变量可以有两种类型:

  • 表面类型
    在定义的时候赋予的类型
  • 实际类型
    对象的类型,如java的表面类型是IDriver,实际类型是Driver。

思考依赖倒置对并行开发的影响。两个类之间有依赖关系,只要制定出两者之间的接口(或抽象类)即可独立开发,而且项目之间的单元测试也可以独立地运行,而TDD(Test-Driven Development,测试驱动开发)开发模式就是依赖倒置原则的最高级应用。

回顾司机驾驶汽车的例子:

  • 甲程序员负责IDriver开发
  • 乙程序员负责ICar的开发

两个开发人员只要制定好了接口就可以独立地开发了,甲开发进度比较快,完成了IDriver以及相关的实现类Driver的开发工作,而乙程序员滞后开发,那甲是否可以进行单元测试呢?
根据抽象虚拟一个对象进行测试:
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》
只需要一个ICar接口,即可对Driver类进行单元测试。
这点来看,两个相互依赖的对象可分别进行开发,各自独立进行单元测试,保证了并行开发的效率和质量,TDD开发的精髓不就在这?
TDD,先写好单元测试类,然后再写实现类,这对提高代码的质量有非常大的帮助,特别适合研发类项目或在项目成员整体水平较低情况下采用。

抽象是对实现的约束,对依赖者而言,也是一种契约,不仅仅约束自己,还同时约束自己与外部的关系,其为保证所有细节不脱离契约范畴,确保约束双方按既定契约(抽象)共同发展,只要抽象这根基线在,细节就脱离不了这个圈圈。

4 依赖

依赖可以传递,A对象依赖B对象,B又依赖C,C又依赖D……
只要做到抽象依赖,即使是多层的依赖传递也无所畏惧!

对象的依赖关系有如下传递方式:

构造器传递

在类中通过构造器声明依赖对象,构造函数注入
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》

4.2 Setter传递

在抽象中设置Setter方法声明依赖关系,Setter依赖注入
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》

4.3 接口声明依赖对象

在接口的方法中声明依赖对象

5 最佳实践

依赖倒置原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立,不互相影响,实现模块间的松耦合

DIP指导下,具体类能少用就少用。
具体类我们还是要用的,毕竟代码要运行起来不能只依赖于接口。那具体类应该在哪用?
这些设计原则,核心关注点都是一个个业务模型。此外,还有一些代码做的工作是负责组装这些模型,这些负责组装的代码就需要用到一个个具体类。

做这些组装工作的就是DI容器。因为这些组装几乎是标准化且繁琐。如果你常用的语言中,没有提供DI容器,最好还是把负责组装的代码和业务模型放到不同代码。

DI容器另外一个说法叫IoC容器,Inversion of Control,你会看到IoC和DIP中的I都是inversion,二者意图是一致的。

依赖之所以可注入,是因为我们的设计遵循 DIP。而只知道DI容器不了解DIP,时常会出现让你觉得很为难的模型组装,根因在于设计没做好。

DIP还称为好莱坞规则:“Don’t call us, we’ll call you”,“别调用我,我会调你的”。这是框架才会有的说法,有了一个稳定抽象,各种具体实现都应由框架去调用。

为什么说一开始TransactionRequest是把依赖方向搞反了?因为最初的TransactionRequest是一个具体类,而TransactionHandler是业务类。

我们后来改进的版本里引入一个模型,把TransactionRequest变成了接口,ActualTransactionRequest 实现这个接口,TransactionHandler只依赖于接口,而原来的具体类从这个接口继承而来,相对来说,比原来的版本好一些。

对于任何一个项目而言,了解不同模块的依赖关系是一件很重要的事。你可以去找一些工具去生成项目的依赖关系图,然后,你就可以用DIP作为一个评判标准,去衡量一下你的项目在依赖关系上表现得到底怎么样了。很有可能,你就找到了项目改造的一些着力点。

理解了 DIP,再来看一些关于依赖的讨论,我们也可以看到不同的角度。
比如,循环依赖,循环依赖就是设计没做好的结果,把依赖关系弄错,才可能循环依赖,先把设计做对,把该有的接口提出来,就不会循环了。

我们怎么在项目中使用这个规则呢?只要遵循以下的几个规则就可以:

  • 每个类尽量都有接口或抽象类,或者抽象类和接口两者都具备
    这是依赖倒置的基本要求,接口和抽象类都是属于抽象的,有了抽象才可能依赖倒置

  • 变量的表面类型尽量是接口或者是抽象类
    很多书上说变量的类型一定要是接口或者是抽象类,这个有点绝对化了

    • 比如一个工具类,xxxUtils一般是不需要接口或是抽象类的
    • 如果你要使用类的clone方法,就必须使用实现类,这个是JDK提供的一个规范。
  • 任何类都不应该从具体类派生
    如果一个项目处于开发状态,确实不应该有从具体类派生出子类的情况,但这也不是绝对的,因为人都是会犯错误的,有时设计缺陷是在所难免的,因此只要不超过两层的继承都是可以忍受的

  • 尽量不要覆写基类方法
    如果基类是一个抽象类,而且这个方法已经实现了,子类尽量不要覆写
    类间依赖的是抽象,覆写了抽象方法,对依赖的稳定性会产生一定的影响

  • 结合里氏替换原则使用
    父类出现的地方子类就能出现, 接口负责定义public属性和方法,并且声明与其他对象的依赖关系,抽象类负责公共构造部分的实现,实现类准确的实现业务逻辑,同时在适当的时候对父类进行细化。

到底什么是“倒置”

依赖正置就是类间的依赖是实实在在的实现类间的依赖,也就是面向实现编程,这也是正常人的思维方式,我要开奔驰车就依赖奔驰车,我要使用笔记本电脑就直接依赖笔记本电脑。
而编写程序需要的是对现实世界的事物进行抽象,抽象的结果就是有了抽象类和接口,然后我们根据系统设计的需要产生了抽象间的依赖,代替了人们传统思维中的事物间的依赖,“倒置”就是从这里产生的

依赖倒置原则是实现开闭原则的重要途径,依赖倒置原则没有实现,就别想实现对扩展开放,对修改关闭。
只要记住面向接口编程就基本上抓住了依赖倒置原则的核心。
《Java新人常问:什么是依赖倒置原则?万字案例给你讲懂!》
依赖倒置原则说的是:
1.高层模块不应依赖于低层模块,二者都应依赖于抽象
2.抽象不应依赖于细节,细节应依赖于抽象
总结起来就是依赖抽象(模型),具体实现抽象接口,然后把模型代码和组装代码分开,这样的设计就是分离关注点,将不变的与不变有效的区分开

防腐层可以解耦对外部系统的依赖。包括接口和参数。防腐层还可以贯彻接口隔离的思想,以及做一些功能增强(加缓存,异步并发取值)。

参考

  • 设计模式之婵
    原文作者:JavaEdge.
    原文地址: https://blog.csdn.net/qq_33589510/article/details/117418515
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞