有了消息发送者这个模型,又该如何把Kafka和这个模型结合呢?
实现一个Kafka的消息发送者:
这样高层模块就不像之前直接依赖低层模块,而是将依赖关系“倒置”,让低层模块去依赖由高层定义好的接口。
好处就是解耦高层模块和低层实现。
若日后替换Kafka,只需重写一个MessageSender,其他部分无需修改。这就能让高层模块保持稳定,不会随低层代码改变。
这就是建立模型(抽象)的意义。
所有软件设计原则都在强调尽可能分离变的部分和不变的部分,让不变的部分保持稳定。
模型都是相对稳定的,而实现细节是易变的。所以,构建稳定的模型层是关键。
====================================================================
抽象不应依赖于细节,细节应依赖于抽象。
简单理解:依赖于抽象,可推出具体编码指导:
- 任何变量都不应该指向一个具体类
如最常用的List声明
-
任何类都不应继承自具体类
-
任何方法都不应该改写父类中已经实现的方法
当然了,如上指导并非绝对。若一个类特稳定,也可直接用,比如String 类,但这种情况很少!
因为大多数人写的代码稳定度都没人家 String 类设计的高。
首先定义一个学习者类
简单的测试类
假如现在又想学习Python,则面向实现编程就是直接在类添加方法
此类需经常改变,扩展性太差,Test 高层模块, Learner 类为低层模块,耦合度过高!
让我们引入抽象:
现在就能将原学习者类的方法都消除
===================================================================
采用依赖倒置原则可减少类间耦合,提高系统稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性。
证明一个定理是否正确,有两种常用方法:
- 顺推证法
根据论题,经过论证,推出和定理相同结论
- 反证法
先假设提出的命题是伪命题,然后推导出一个与已知条件互斥结论
反证法来证明依赖倒置原则的优秀!
依赖倒置原则可减少类间的耦合性,提高系统稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性。
不使用依赖倒置原则也可减少类间的耦合性,提高系统稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性。
通过一个例子来说明反论题不成立!
- 司机驾驶奔驰车类图
奔驰车可提供一个方法run,代表车辆运行:
司机通过调用奔驰车的run方法开动奔驰车
有车,有司机,在Client场景类产生相应的对象
现在来了新需求:张三司机不仅要开奔驰车,还要开宝马车,又该怎么实现呢?
走一步是一步,先把宝马车产生出来
宝马车产生了,但却没有办法让张三开起来,为什么?
张三没有开动宝马车的方法呀!一个拿有C驾照的司机竟然只能开奔驰车而不能开宝马车,这也太不合理了!在现实世界都不允许存在这种情况,何况程序还是对现实世界的抽象。
我们的设计出现了问题:司机类和奔驰车类紧耦合,导致系统可维护性大大降低,可读性降低
。
两个相似的类需要阅读两个文件,你乐意吗?还有稳定性,什么是稳定性?固化的、健壮的才是稳定的,这里只是增加了一个车类就需要修改司机类,这不是稳定性,这是易变性。
被依赖者的变更竟然让依赖者来承担修改成本,这样的依赖关系谁肯承担?
证明至此,反论题已经部分不成立了。
继续证明,“减少并行开发引起的风险”
什么是并行开发的风险?
并行开发最大的风险就是风险扩散,本来只是一段程序的异常,逐步波及一个功能甚至模块到整个项目。一个团队,一二十个开发人员,各人负责不同功能模块,甲负责汽车类的建造,乙负责司机类的建造,在甲没有完成的情况下,乙是不能完全地编写代码的,缺少汽车类,编译器根本就不会让你通过!在缺少Benz类的情况下,Driver类能编译吗?更不要说是单元测试了!在这种不使用依赖倒置原则的环境中,所有开发工作都是“单线程”,甲做完,乙再做,然后是丙继续……这在20世纪90年代“个人英雄主义”编程模式中还是比较适用的,一个人完成所有的代码工作。但在现在的大中型项目中已经是完全不能胜任了,一个项目是一个团队协作的结果,一个“英雄”再牛也不可能了解所有的业务和所有的技术,要协作就要并行开发,要并行开发就要解决模块之间的项目依赖关系,那然后呢?
依赖倒置原则隆重出场!
根据以上证明,若不使用依赖倒置原则就会加重类间的耦合性,降低系统的稳定性,增加并行开发引起的风险,降低代码的可读性和可维护性。
引入DIP后的UML:
建立两个接口:IDriver和ICar,分别定义了司机和汽车的各个职能,司机就是驾驶汽车,必须实现drive()方法
接口只是一个抽象化的概念,是对一类事物的最抽象描述,具体的实现代码由相应的实现类来完成
IDriver通过传入ICar接口实现了抽象之间的依赖关系,Driver实现类也传入了ICar接口,至于到底是哪个型号的Car,需要声明在高层模块。
ICar及其两个实现类的实现过程:
业务场景应贯彻“抽象不应依赖细节”,即抽象(ICar接口)不依赖BMW和Benz两个实现类(细节),因此在高层次的模块中应用都是抽象:
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的开发工作,而乙程序员滞后开发,那甲是否可以进行单元测试呢?
根据抽象虚拟一个对象进行测试:
只需要一个ICar接口,即可对Driver类进行单元测试。
这点来看,两个相互依赖的对象可分别进行开发,各自独立进行单元测试,保证了并行开发的效率和质量,TDD开发的精髓不就在这?
TDD,先写好单元测试类,然后再写实现类,这对提高代码的质量有非常大的帮助,特别适合研发类项目或在项目成员整体水平较低情况下采用。
抽象是对实现的约束,对依赖者而言,也是一种契约,不仅仅约束自己,还同时约束自己与外部的关系,其为保证所有细节不脱离契约范畴,确保约束双方按既定契约(抽象)共同发展,只要抽象这根基线在,细节就脱离不了这个圈圈。
===================================================================
依赖可以传递,A对象依赖B对象,B又依赖C,C又依赖D……
只要做到抽象依赖,即使是多层的依赖传递也无所畏惧!
对象的依赖关系有如下传递方式:
在类中通过构造器声明依赖对象,构造函数注入
在抽象中设置Setter方法声明依赖关系,Setter依赖注入
在接口的方法中声明依赖对象
=====================================================================
依赖倒置原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立,不互相影响,实现模块间的松耦合
。
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,再来看一些关于依赖的讨论,我们也可以看到不同的角度。
比如,循环依赖,循环依赖就是设计没做好的结果,把依赖关系弄错,才可能循环依赖,先把设计做对,把该有的接口提出来,就不会循环了。
我们怎么在项目中使用这个规则呢?只要遵循以下的几个规则就可以:
- 每个类尽量都有接口或抽象类,或者抽象类和接口两者都具备
这是依赖倒置的基本要求,接口和抽象类都是属于抽象的,有了抽象才可能依赖倒置