模式误用与过度设计
设计模式是描述解法的词汇表，不是目标。GoF 原书明确它记录的是对常见问题的可复用解法，是否适用取决于变化点是否真实存在。没有第二种实现、没有第二个变化轴就套模式，只会多出类型与间接层，读代码的人要付出理解成本却换不来灵活性。
基本信息
| 来源 | GoF《设计模式》序言：模式是对重复问题的解法描述，非普适 |
|---|---|
| 识别信号 | 抽象层无对应扩展压力、接口只有单一实现、类名写着模式名却说不清意图 |
| 代价 | 类型与间接层增多，新人上手成本上升 |
| 习惯 | 先写直白实现，真的出现变化点再引入模式 |
常见过度设计形态
- 为「将来可能换数据库」抽出仓储接口，实际只有一套实现且从不替换
- 用抽象工厂管理只有一种风格的产品族
- 把一次性的数据变形封装成多层策略加注册表
- 为三个 if 引入责任链，链的装配逻辑比判断还长
- 声明式配置驱动的通用引擎，配置项只有一处在用
评审自检问题
评审自检问题
□ 这个模式消除的具体坏味道是什么？（写出名字）
□ 不用它，最坏情况会怎样？成本可接受吗？
□ 当前存在第二种实现或第二个变化轴吗？
□ 新增一个同类实现，是加文件还是改多处？
□ 半年后新人能读懂并敢改这层抽象吗？信号与处理
| 信号 | 说明 | 处理 |
|---|---|---|
| 接口单实现 | 抽象没有被任何替换压力驱动 | 内联回具体实现 |
| 类名带模式词 | 命名靠模式撑场面，意图没写清 | 按职责重命名 |
| 配置项闲置 | 开关与分支从未被触发 | 删除分支与配置 |
| 间接层追查费力 | 一次调用跳转超过三处 | 合并为直白流程 |
与「夸夸其谈通用性」这条坏味道互查：「现在不需要，但将来可能要用」通常就是删除信号。删除前先确认变化点是否真实存在，别把已经出现过的第二种实现一起删掉。