设计模式学习笔记（一）——六大设计原则

一、六大设计原则概述

构成：在面向对象五大设计原则（SOLID 原则）基础上加上迪米特法则，即：
- 单一职责原则(Single Responsibility Principle)
- 开闭原则(Open/Closed Principle)
- 里氏替换原则(Liskov Substitution Principle)
- 接口隔离原则(Interface Segregation Principle)
- 依赖倒置原则(Dependency Inversion Principle)
- 迪米特法则(Law of Demeter)

设计原则处于语法规则和常见设计模式之间。语法规则必须严格遵守，否则程序无法正常运行或编译；设计模式用于优化程序设计架构，可根据情况适度使用；六大原则不严格遵守程序仍能运行，但违背会使代码设计从设计层面绝对错误，极具破坏性，因此被称为原则或法则。

二、具体原则

1. 单一职责原则

一个类只能承担一种功能。

• 目的
  • 降低耦合性：出现问题时方便定位和调试。
  • 增强可读性和可维护性：功能越少代码越清晰，更新迭代时关注范围窄，不易遗漏。
  • 提高复用性：功能拆分越细，越容易无副作用地用同一套代码解决相似需求。

严格遵循单一职责原则会使代码繁重且灵活性差，可考虑组合模式或 ECS 架构思想。

2. 开闭原则

对扩展开放，对修改封闭。需求改变时，通过扩展编写新代码而非修改已有代码来实现功能变更或添加新功能模块。

• 目的
  • 降低风险：修改已稳定的代码可能会引入新Bug，扩展可以降低风险，避免触动未知代码引发雪崩效应，在团队协同开发中尤为重要。
  • 提升效率：提前设计好扩展性强的系统，为后续迭代节省时间成本。
• 实践形式：子类重写父类方法，如在模板方法模式中父类决定算法骨架、子类重写算法步骤。

3. 里氏替换原则

所有父类出现的地方都可以使用子类对象来替换，且不会改变程序的正确性，是对继承逻辑正确性的保障，确保多态机制正常发挥作用。

• 目的
  • 保障继承体系的正确性：如果子类不完全遵循父类契约，调用者可能会遇到意想不到的问题。
  • 提高代码复用性：符合LSP的设计能使多态机制充分发挥作用，增强系统扩展性。
• 实现要求
  • 子类方法参数：必须与父类参数类型相匹配，或更加抽象。
  • 子类方法返回值：必须与父类方法返回值类型或其子类型相匹配。
  • 异常处理：父类中的方法不应该抛出基类方法预期之外的异常类型。
  • 前置条件：子类不应该加强其前置条件。
  • 后置条件：子类不能削弱其后置条件。
  • 不变量：父类的不变量（形式上的规则）必须保留。
  • 私有成员变量：子类不能修改父类中私有成员变量的值（无论当前的开发语言是否在语法层面进行了限制）。

4. 接口隔离原则

核心是将大而全的通讯接口拆分成更小、关注点更精细的细分接口，避免多余依赖和耦合，增强灵活性。

如游戏对象设计可拆分为更新和渲染两个接口逻辑，玩家角色实现可更新和可渲染接口，静态背景仅实现渲染接口。

与单一职责原则关系：与单一职责原则异曲同工，都旨在减少依赖和耦合。

5. 依赖倒置原则

高层次的类不应该依赖低层次的类，而是将二者的依赖转嫁到抽象接口之上。高层次类指软件层面的功能，如按钮响应、界面显示等，低层次类指底层架构，如文件 IO、网络通信、数据库连接等。

如游戏业务逻辑类（Game 类）设计之初依赖低层次的网络通信类（TCP 类），后续更换协议时若直接依赖具体类则需修改内部代码，而抽象出网络接口（Network 接口）后，Game 类仅调用抽象接口的 Send 与 Receive 方法，切换底层实现时高层代码无需修改。

要求：对开发者架构能力要求高，避免业务类直接依赖具体的底层实现。

6. 迪米特法则（最少知识原则）

一个对象只与其最直接关联的对象进行通信，避免与陌生对象产生耦合，减少链式调用和过多间接依赖。

如Player需要给Pet喂食，应该直接与Pet对象通信，而不是调用Hand对象，再通过Hand对象调用Pet的喂食逻辑。

• 目的：
  • 降低系统耦合性：减少单个对象变化引发调用链上其他对象功能问题的风险，防止因某个对象的变化影响过多其他对象。
  • 增强系统稳定性：每个模块只关注自己的直接关系，便于测试和维护。

三、总结

六大设计原则适用于几乎所有使用面向对象思想进行架构的软件开发，初学时可能觉得遵循这些原则多此一举、干扰编码思路，但有意识地遵守、思考和反思，这些规范在未来开发生涯中大有用处。