II. Design Patterns Revisited

为什么“II. Design Patterns Revisited”从问题证据开始

经典模式被背成类图后，名称相似会掩盖完全不同的变化轴。本页不把模式当成必选答案，而是先保存无模式基线，再验证候选机制是否真正改变可观察结果。通过条件是“同一问题只引入能解释首要变化轴的最小机制”，而不是类或接口数量增加。

来源、版本与独立重写边界

本页用作者完整在线正文核对正式标题、设计分叉和时代语境，并以作者源码仓库交叉检查结构。仓库许可证明确正文、HTML与样式为 CC BY-NC-ND 4.0，示例程序等其他文件为 MIT；因此下列中文解释、图示、交互和代码均为独立教学重写，不翻译、拼接或改写受 ND 限制的原文表达。

本章机制与术语

理解本章需要四个核心概念：

• 设计模式（design pattern）：见术语复核。
• 重访（revisited）：见术语复核。
• GoF（Gang of Four）：见术语复核。
• 变化轴（axis of change）：见术语复核。

官方结构逐项深读

II. Design Patterns Revisited

第二部分重访六个GoF模式，重点比较它们在实时游戏中的价值、误用与现代替代。

II. Design Patterns Revisited 的因果解释从“识别问题”开始：先标出输入、所有者和可见结果，再说明以命令、享元、观察者、原型、单例和状态的失败模型做横向选择。若没有模式的基线也能更简单地守住“同一问题只引入能解释首要变化轴的最小机制”，这一节点应得出“不采用”的结论。

II. Design Patterns Revisited 的验证只改变一个条件，记录依赖边、生命周期、分配轨迹与替代方案；随后注入“为了模式数量同时叠加单例、观察者和命令”，定位首个分叉并执行重置。这样该节点同时具备出现、解释、专属实验和练习验证四级证据。

The Patterns

分部导言建立模式之间的选择坐标，模式名称不是结论，问题、约束与反例才是选择依据。

The Patterns 的因果解释从“列出候选”开始：先标出输入、所有者和可见结果，再说明以命令、享元、观察者、原型、单例和状态的失败模型做横向选择。若没有模式的基线也能更简单地守住“同一问题只引入能解释首要变化轴的最小机制”，这一节点应得出“不采用”的结论。

The Patterns 的验证只改变一个条件，记录依赖边、生命周期、分配轨迹与替代方案；随后注入“为了模式数量同时叠加单例、观察者和命令”，定位首个分叉并执行重置。这样该节点同时具备出现、解释、专属实验和练习验证四级证据。

可迁移实现或计算骨架

initial state -> 识别问题 -> 列出候选 -> 比较时序 -> 比较代价 -> 选择最小项
fault injection -> 为了模式数量同时叠加单例、观察者和命令
pass condition -> 同一问题只引入能解释首要变化轴的最小机制
reset -> initial state

该骨架只保存实验合同；真实项目还要把平台、构建、场景、输入和统计窗口固定下来，并保留基线实现以便回退。

本章练习与节点验证矩阵

术语复核与本章回顾

掌握“II. Design Patterns Revisited”意味着能从“经典模式被背成类图后，名称相似会掩盖完全不同的变化轴”出发，解释以命令、享元、观察者、原型、单例和状态的失败模型做横向选择，再用依赖边、生命周期、分配轨迹与替代方案推翻或保留实现。若“同一问题只引入能解释首要变化轴的最小机制”不能稳定复现，本章仍未通过。

🔮 猜一猜：GoF 的 Command 模式在游戏里最常见的用途是什么？

术语复核

本章练习与节点验证矩阵

阅读导航

← 上一页：1. Architecture, Performance, and Games · 下一页：2. Command →