游戏编码中的设计模式（公众号笔记）
ABSTRACT
2021-05 笔记。以游戏开发视角讲面向对象 7 大设计原则（SRP/OCP/LSP/DIP/ISP/LKP/组合优先），强调原则是 GOF 23 种模式的地基，并附「依赖注入并非教条」的开放态度。
核心要点
- 设计模式定义：一再出现的问题的可复用解法核心，可举一反三；23 种 GOF 模式不是教条，未被收录的优秀方案（如依赖注入/控制反转）同样是模式。
- 单一职责（SRP）：类只负责一件事；实践中会不断往类上加功能导致耦合，靠持续「类重构 + 组合」抽离回归单一职责。
- 开闭原则（OCP）：对扩展开放、对修改封闭；进入测试/维护期后不改旧类，通过功能接口化 + 新增子类满足新需求。
- 里氏替换（LSP）：子类必须可替换父类；客户端不做强制向下转型，不应知道正在使用哪个子类。
- 依赖倒置（DIP）：高层不依赖低层，都依赖抽象；电脑定义 USB 接口、外设遵循接口实现是经典类比；变量声明类型尽量是接口/抽象类，不做类型转换，子类不新增接口外方法。
- DIP 落地建议：类尽量继承接口/抽象类；避免从具体类派生（继承深度不超过两层可接受）；维护期工程师可放宽——覆盖一个方法修复大 bug 是务实选择。
- 接口隔离（ISP）：客户端不应被迫使用用不到的方法；通过功能切分、接口简化降低类复杂度。
- 最少知识（LKP）：类少依赖其他类的「知识」，降低耦合、提高复用性。
- 组合优于继承：闹钟继承时钟会暴露用户不需要的方法，改为持有「时钟类成员」更干净；Java/C# 无多重继承，组合更易维护。
- 学习路径：先理解 7 原则，再学 23 种模式。
关键实体与概念
SOLID 五原则、最少知识原则、组合优于继承、GOF 23 种设计模式、依赖注入、控制反转、类重构
关联概念
来源回溯
- 原始文件：
raw/ip/wechat_articles/游戏编码中的设计模式.md（2021-05-13）
时效性评估
- 仍有效：SOLID 与组合优先是面向对象设计的持久原则，不随框架演进贬值；「维护期务实放宽规则」的观点尤其贴近真实工程。
- 已过时：游戏行业近年兴起 ECS/DOTS 数据导向范式，对「类继承体系」本身是另一种回答——原则仍适用，但对象建模的默认姿势在性能敏感场景已从 OOP 转向 DOD；函数式思想（不可变、纯函数）也成为组合之外的常见解。