设计模式之设计原则(一)

简介

什么是设计模式?

每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题的解决方案的核心,这样,你就能不必一次又一次地使用该方案而不必重复劳动。

深入理解面向对象

向下:三大面向对象机制

  • 封装:隐藏内部实现
  • 继承:复用现有代码
  • 多态:改写对象行为

现上:深刻把握面向对象机制带来的抽象意义,理解如何使用这些机制来表达现实世界,掌握什么是“好的面向对象设计”

软件设计复杂的根本原因

变化:

  • 客户需求的变化
  • 技术平台的变化
  • 开发团队的变化
  • 市场环境的变化

如何解决复杂性?

分解

  • 人们面对复杂性有一个常见的作法:分而治之,将大问题分解为多个小问题,将复杂问题分解为多个简单问题。

抽象

  • 更高层次来讲,人们处理复杂性有一个通用的计数,即抽象。由于不能掌握全部的复杂对象,我们选择忽视它的非本质细节,而去处理泛化和理想化了的对象模型。

设计原则

单一职责原则(SRP)

一个接口仅负责一个职责,一个类只能由一个原因引起变化。

优点:

  • 类的复杂性降低,实现什么职责都有清晰明确的定义
  • 可读性提高
  • 可维护性提高
  • 变更引起的风险降低,变更时必不可少的,如果接口的单一职责做好,一个接口的修改只对相对应的实现类有影响。

里氏替换原则(LSP)

所有引用基类的地方必须能透明的使用其子类的对象。

只要父类能出现的地方子类就可以出现,而且替换为子类也不会产生任何错误或异常。

  • 子类必须完全实现父类的方法
  • 子类可以有自己的方法和属性
  • 覆盖或实现父类的方法时输入参数可以被放大
  • 覆写或实现父类的方法时输出结果可以被缩小

依赖倒置原则(DIP)

  • 高层模块不应该依赖低层模块,两者都应该依赖其抽象
  • 抽象不应该依赖细节
  • 细节应该依赖抽象

在Java语言中的表现:

  • 模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生的
  • 接口或抽象类不依赖于实现类
  • 实现类依赖接口或抽象类

对象的依赖关系有三种方式来传递:

  • 构造函数传递依赖对象
  • Setter方法传递依赖对象
  • 接口声明依赖对象

如何实践?

  • 每个类尽量都有接口或抽象类,或者抽象类与接口两者都具备
  • 变量的表面类型尽量是接口或者抽象类
  • 任何类都不应该从具体类派生
  • 尽量不要覆写基类的方法
  • 结合里氏替换原则使用:接口负责定义public属性和方法,并且声明与其他对象的依赖关系,抽象类负责公共内部构造部分的实现,实现类准确的实现业务逻辑,统统实在适当的时候对父类进行细化。

接口隔离原则(ISP)

  • 客户端不应该依赖它不需要的接口
  • 类间的依赖关系应该建立在最小的接口上

接口分为两种:

  • 实例接口:在Java中声明一个类,然后用new关键字产生一个实例,它就是对一个类型的事物的描述,这是一种接口
  • 类接口:interface关键字定义的接口

接口隔离原则对接口进行规范约束,包含以下四个含义:

  • 接口要尽量小
  • 接口要高内聚,减少对外的交互(尽量少公布public方法)
  • 定制服务(只提供访问者需要的方法)
  • 接口设计是有限度的(粒度越小,系统越灵活,结构越复杂,开发难度增加,可维护性降低)

如何实践?

  • 一个接口只服务于一个子模块或业务逻辑
  • 通过业务逻辑压缩接口中的public方法
  • 已经被污染的方法,尽量去修改,若变更风险较大,则采用适配器模式进行处理
  • 了解环境,深入理解业务逻辑,结合实际。

迪米特法则(LoD)

一个对象应该对其他对象有最少的了解。

类和类关系越密切,耦合度越大。

也称为最少知识原则(LKP),通俗的讲:一个对象应该对自己需要耦合或者调用的类知道的最少,你的内部如何复杂和我都没有关系,我就知道你提供这么多public方法,我就调用这么多,其他我一概不关心。

迪米特法则对类的低耦合提出了明确的要求,其包含以下四层含义:

  • 只和朋友交流(朋友类:出现在成员变量,方法输入输出参数的类)。
  • 朋友之间有距离的。
  • 是自己的就是自己的(一个方法放在本类种,既不增加类间关系,也对本类不产生负面影响,那就放在本类之中)。
  • 谨慎使用Serializable。

迪米特法则的核心观念就是类间解耦,弱耦合,只有弱耦合之后,类的复用率才可以提高,要求的结果就是产生了大量中转或跳转类,导致系统复杂性提高,同时也为维护带来了难度。

开闭原则(OCP)

一个软件实体如类,模块和函数应该对扩展开放,对修改关闭。

  • 对扩展开放(提供方),对修改关闭(使用方)
  • 用抽象构建框架,用实现扩展细节
  • 一个软件实体应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化。
  • 遵循的所有原则,以及设计模式的目的就是遵循开闭原则。
文章作者: L1nker4
文章链接: https://l1n.wang/2020/05/design-principle/
版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 L1nker4's Blog