设计模式 | 设计原则

176 阅读5分钟

1、主要原则

  • 可维护性:软件能够被理解、改正、适应及扩展的难易程度
  • 可复用性:指软件能够被重复使用的难易程度

2、概述

  • 面向对象设计原则为支持可维护性复用而诞生
  • 指导性原则,非强制性原则
  • 每一个设计模式都符合一个或多个面向对象设计原则,面向对象设计原则是用于评价一个设计模式的使用效果的重要指标之一

3、原则详解

(1)单一职责

就一个类而言,应该仅有一个引起它变化的原因(提高可复用性)

  • 一个类(大到模块,小到方法)承担的职责越多,它被复用的可能性就越小
  • 当一个职责变化时,可能会影响其他职责的运作
  • 将这些职责进行分离,将不同的职责封装在不同的类中,将不同的变化原因封装在不同的类中
  • 单一职责原则是实现高内聚、低耦合的指导方针

(2)开闭原则(最重要的面向对象设计原则)

软件实体应当对扩展开放,对修改关闭。

  • 抽象化是开闭原则的关键
  • 相对稳定的抽象层 + 灵活的具体层
  • 对可变性封装原则:找到系统的可变因素并将其封装起来

(3)里氏代换原则

所有引用基类的地方必须能透明地使用其子类的对象。如果一个软件实体使用的是一个子类对象的话,那么它不一定能够使用基类对象来替代,但是基类则可以用子类来替换。(喜欢动物--->喜欢狗,喜欢狗不能推出喜欢动物)

(4)依赖倒转原则

高层模块不应该依赖低层模块,它们都应该依赖抽象。抽象不应该依赖于细节,细节应该依赖于抽象。

  • 在程序代码中传递参数时或在关联关系中,尽量引用层次高的抽象层类,即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明,以及数据类型的转换等。
  • 在程序中尽量使用抽象层进行编程,而将具体类写在配置文件中,系统发生变换则只要对抽象层进行拓展,无需修改源代码。
  • 针对接口编程而不是针对实现编程,具体类对象通过依赖注入(通过方法参数注入:构造函数注入,业务方法注入,设值注入,这些方法申明时都是抽象类型,运行时再传入具体类型,子类覆盖父类)。

(5)接口隔离原则

客户端不应该依赖那些它不需要的接口。

  • 当一个接口太大时,需要将它分割成一些更细小的接口
  • 使用该接口的客户端仅需知道与之相关的方法即可
  • 每一个接口应该承担一种相对独立的角色,不干不该干的事,该干的事都要干
  • 【补】接口
    • 定义(1):一个类型所提供的所有方法特征的集合。一个接口代表一个角色,每个角色都有它特定的一个接口,“角色隔离原则”。
    • 定义(2):狭义的特定语言的接口。接口仅仅提供客户端需要的行为,客户端不需要的行为则隐藏起来,应当为客户端提供尽可能小的单独的接口,而不要提供大的总接口,每个接口中只包含一个客户端所需的方法,“定制服务”。

(6)合成复用原则

优先使用对象组合,而不是继承来达到复用的目的。

  • 新对象通过委派调用已有对象的方法达到复用功能的目的
  • 复用时要尽量使用组合/聚合关系(关联关系),少用继承

(7)迪米特法则

每一个软件单位对其他的单位都只有最少的知识,而且局限于那些与本单位密切相关的软件单位。(不要和陌生人说话)

  • 迪米特法则要求一个软件实体应当尽可能少地与其他实体发生相互作用,降低系统的耦合度(一个对象要调用另一个对象的方法,可以引入第三者进行间接通信),使类与类之间保持松散的耦合关系,一个处在松耦合中的类一旦被修改,不会对关联的类造成太大影响
  • 不满足以下条件的对象尽量不进行直接交互。在类的结构设计上,每一个类都应当尽量降低其成员变量和成员函数的访问权限,一个对象对其他类的对象的引用应当降到最低
  • 朋友:
    • 当前对象本身(this)
    • 以参数形式传入到当前对象方法中的对象
    • 当前对象的成员对象
    • 如果当前对象的成员对象是一个集合,那么集合中的元素也都是朋友
    • 当前对象所创建的对象
  • 在类的设计上,只要有可能,一个类型应当设计成不变类