python-design-patterns

Python 设计模式

为下一个真实的改动而设计，而不是为想象中的未来灵活性而设计。在复杂性证明其价值之前，简单的代码更胜一筹。

如需查看具体的改动前后示例，请阅读 references/pattern-catalog.md。

决策原则

• KISS： 选择能满足当前需求的最简单设计。
• 单一职责： 每个函数／类／模块只因一个原因而改变。
• 组合优于继承： 在构建脆弱的继承层级之前，先显式组合行为。
• 三次原则： 在第三个案例证明模式确实存在之前，不要抽象两个相似案例。
• 依赖方向： 业务逻辑不应依赖框架胶水代码。

重构工作流

1. 找出痛点：重复、耦合、函数过长、归属不清、难以测试，或反复出现的缺陷模式。
2. 明确设计必须支持的改动。
3. 找出能够缓解痛点的最小边界。
4. 优先提取纯函数，而不是类。
5. 只有在抽象能消除实际重复或隔离易变部分时，才引入抽象。
6. 移动代码前，先确保行为测试仍然存在。

常见做法

• 将连贯的转换提取为函数。
• 将相关函数提取到模块中，以便它们可以一起变化。
• 只有在多个实现确实存在时，才引入协议／接口。
• 将依赖作为参数传入，以便于测试。
• 只有在持久化或业务逻辑确实纠缠在一起时，才使用仓库／服务边界。

避免

• 在存在多个实际变体之前就引入工厂、注册表和插件。
• 只有一个子类的基类。
• 全局可变状态。
• 渗入公共 API 模式的框架模型。
• 只负责转发调用的“整洁架构”分层。

输出

返回：

• 当前的设计异味；
• 导致问题的具体压力；
• 最小重构方案；
• 暂时应避免的抽象；
• 对测试的影响；
• 改动前后的归属边界。