【Java】面向对象设计原则和设计模式关系及如何实践

1. 概述

设计模式,面向对象原则,软件质量属性的关系如下图: 【Java】面向对象设计原则和设计模式关系及如何实践

  1. 上层所作的一切都是为了最终能提高软件质量属性。
  2. 设计原则基于面向对象三大原则,这三大原则是上层的基础。
  3. 封装变化是面向接口编程的基础,如果没有变化就没有必要面向接口编程,因此封装变化尤为重要。
  4. 设计模式遵循了设计原则和面向对象三大原则,同时又是这些原则的落地实践参考。

以上各层互相关联,需要综合来看才能更好的落地实践,提高个人能力和软件质量。

2. 设计原则

这里并不会对设计原则做详细介绍,这方面的资料较多,可以参考其他资料一起着看,这里仅描述基本概念和一些体会。

2.2. 单一职责

参考Java编程思想(八)如何做到单一职责 。

2.3. 开闭原则

2.3.1. 定义

对扩展开放,对修改封闭。可以理解为尽量对已有类/模块的修改封闭,可以增加新的类实现扩展。

2.3.2. 例子

算税根据不同的场景计算方法不同,需要动态获取算法,同时允许定制团队扩展税的算法。

  1. 这里税的算法是变化点,因此需要抽象出来。
  2. 定制团队要能扩展税的算法,因此需要支持动态注册算法。

最终得到的类结构图如下: 【Java】面向对象设计原则和设计模式关系及如何实践

这样当有新的税算法时:

  1. 实现新的税算法类
  2. 增加一个新的税类型和新算法类对应
  3. 通过TaxCalculatorRegistry类注册新的税算法类
  4. 通过TaxCalculatorRegistry获取对应的税算法类算税

2.4. 里氏替换

2.4.1. 定义

子类对象能够替换父类对象,并且保证原来程序的逻辑行为不变及正确性不被破坏。

这个定义看起来很像面向接口编程,但实际两者不同,里氏替换原则满足面向接口编程,但是面向接口编程未必满足里氏替换原则,里氏替换原则还包含了约束,强调程序的逻辑行为不变及正确性不被破坏。

2.4.2. 例子

一个接口的子类原来性能差,替换了新的子类实现,接口不变,但是某个方法原来未抛异常,新的子类抛了运行时异常,这就改变了原来的逻辑行为,会影响调用端的处理逻辑,严格讲不符合里氏替换原则。

当代码被第三方调用时尤其要注意里氏替换原则,如果未告知抛异常情况下突然抛了异常,很有可能严重影响调用端的处理逻辑。

2.5. 接口隔离

2.5.1. 定义

接口的设计要尽量单一,不要让接口的实现类和调用者,依赖不需要的接口函数。

2.5.2. 例子

鸭子会叫,会游泳,会飞,但并非所有的鸭子都会游泳,会飞(例如塑料鸭),因此需要做接口隔离分别定义游泳和飞的接口。

如果不做接口隔离,那么塑料鸭子就要实现不必要的接口,但实际又不能有对应实现,只能抛出UnSupportException异常,有点多此一举,没有意义。

2.5.4. 例外

在实际工作中,有时会违背这样的原则,将所有的接口定义在一起,在不支持子类实现中抛出UnSupportException,这种做法其实违背了接口隔离原则,但有时也是不得已为知,因为接口不是自己定义的,是开源框架或者业界标准接口定义,比如JDBC相关的接口,在和公司自行实现的数据库对接时,未必能支持所有方法,但又不得不通过JDBC接口做标准化。

因此,此原则应尽量遵守,也可以有例外。

2.6. 依赖倒置

2.6.1. 定义

高层模块不依赖低层模块,它们共同依赖同一个抽象。抽象不要依赖具体实现细节,具体实现细节依赖抽象。

2.6.2. 例子

通常情况下,高层会依赖低层,但这样就没有了扩展性,会依赖低层的实现细节,依赖倒置通常出现在业界的一些标准规范,框架等等,例如JDBC接口规范:
【Java】面向对象设计原则和设计模式关系及如何实践
调用者只需要依赖JDBC接口,而不用关心各个厂家的具体实现类。

类似的例子还有servlet规范,开发者只要实现servlet的接口就能在对应的web容器中被调用。

依赖倒置原则减少了低层耦合,适用于框架,模块间,系统间的调用。

2.7. 迪米特法则

2.7.1. 定义

迪米特法则(Law of Demeter)又叫作最少知识原则(The Least Knowledge Principle),一个类对于其他类知道的越少越好,就是说一个对象应当对其他对象有尽可能少的了解,只和朋友通信,不和陌生人说话。英文简写为: LOD

2.7.2. 例子

设计模式的门面模式(Facade)和中介模式(Mediator),都是迪米特法则应用的例子。

3. 面向对象三大原则

3.1. 封装变化

封装变化的好处显而易见,向上支持设计原则,向下保证了软件的多个质量属性。 那么怎么才能提高封装变化的能力?

通常可以在设计阶段先做分析,初步识别哪些功能可能是变化点,画出大致的类结构图,开始编码,但实际上设计阶段有的细节考虑不到,另外也并不是每个人都会设计先行,因此还可以通过逆向的方式识别变化点,过程如下:

  1. 编写代码时每个方法尽量不要超过20行,当你这么做以后,每个可以独立存在的方法都可能是一个变化点。(方法短小不仅仅可以用来识别变化点,同时也能提高可维护性,好比一篇文章,为啥要有章节,没有章节目录的书如果内容又长,估计你都不想看,所以编写短小方法应该始终贯彻到底)
  2. 检查每个方法的实现是否可能发生变化,是否可提取成公共方法,如果答案为肯定,就意味着你要提供接口,拆分类,使用工厂,策略等设计模式
  3. 进一步检查这个变化点是否允许第三方来扩展,如果答案为肯定,意味着你可能要提供动态注册变化点的实现类的能力,或者是对外提供的方法允许通过接口注入具体的实现类。
  4. 进一步检查变化点是否需要独立为一个子包,或者是项目级的公共包

按照以上方式步骤不断重构就可以了。

注意事项:

  1. 每个可独立的方法不一定就要做成public,要根据实际需要决定是否要做成public,方法独立最基本的作用是提高可维护性。
  2. 要充分考虑变化的可能性,如果可能性不大,就不要作为变化点处理,不要为了让代码看起来很高大尚就搞出接口,设计模式来,代码简单,稳定更重要。

《2020最新Java基础精讲视频教程和学习路线!》

链接:https://juejin.cn/post/691865...

以上是 【Java】面向对象设计原则和设计模式关系及如何实践 的全部内容, 来源链接: utcz.com/a/102026.html

回到顶部