设计原则
参考链接:https://datawhalechina.github.io/sweetalk-design-pattern/#/content/design_principles/dependence_inversion_principle
主要介绍以下五个设计原则:
1、单一职责原则
顾名思义,一个类只有一个职责,只会因为一个原因修改它。
为了便于代码维护、修改和复用,需要遵循单一职责原则,将不同职责划分开到不同的类中去实现,每个类只负责一个职责。
比如说《大话设计模式【java溢彩加强版】》中的一个计算器例子,在该例子中,要求输入两个数字,进行加减乘除操作。
正常思维就是卡卡一顿写,先写输入,然后根据输入进行运算判断,最终进行运算操作,输出结果。整个流程发生在一个类中,具体如下:
易知上述的控制台输入和计算是合并在一块的,并不灵活,也不方便后期的维护和扩展。正确的做法应该是将计算和显示功能分开来。同时计算的逻辑也可以复用到别的地方。
2、开闭原则
开闭原则要求对扩展开放,对修改关闭,即在新增功能时最好是在现有的代码进行扩展,而不是修改现有的代码。
还是延续上述计算器例子,根据例子要求,对数字进行加减乘除操作,很容易联想到之后的改变,若要增加其他操作,就要在已有代码的基础上,不停的添加运算分支。且需要对开发人员提供所有运算的代码,这显然是没有必要的。
因此,正常的做法是将运算操作抽象出来得到Operation父类,然后构建不同运算的子类(Add/Sub/Mul/Div)去继承父类,每个子类重写运算方法来实现不同运算操作。这样以后出现新的功能要求,比如添加求幂运算,就只需要添加一个求幂运算的子类即可。
具体代码如下:
Operation运算类
加法和减法类
3、依赖倒置原则
程序不依赖细节,而依赖于抽象。
在实际应用中,通过接口或者抽象类制定规范,再用实现类去实现具体的细节,实现松耦合。
以计算器例子来说,我们将运算操作抽象出来得到Operation类,具体细节让Add/Sub等实现类去实现。
4、里氏替换原则
子类能够替换它们的父类,即父类能够复用,子类能在父类的基础上进行扩展。
具体使用:
- 父类一般使用抽象类或者接口。
- 抽象类定义公共对象和状态;接口定义公共行为。
- 子类通过继承父类和接口进行扩展。
5、迪米特原则
也叫最小知识原则,强调两个类之间的松耦合,不必发生直接联系,而是通过第三者来中转。同时减少类对外公开的方法和变量。
以买房子为例,以下内容来源博客:https://blog.csdn.net/weixin_44564365/article/details/87920573
人直接知道房子的信息(包括大小、装修、层数),如下图:
这显示不符合迪米特原则以及实际情况,于是通过添加一个中介类来减少耦合:
这还存在一个问题,如果中介跑了,或者房子不卖了,怎么办?于是再次进行改进添加中介公司接口和房源接口。
这样买房的时候就可以找中介公司,中介公司找中介,也可以找房子,更方便、灵活,也应用到了依赖倒置原则!