设计模式非必需，而是成熟经验总结；小项目优先写清晰可运行代码，中大型项目用模式降低协作成本；Python特性使部分模式简化；应关注代码坏味道而非强行套用模式。
设计模式不是必须的，但它是解决常见软件设计问题的成熟经验总结。是否需要，取决于项目规模、团队协作需求和长期维护成本。
小脚本或一次性任务，通常不需要
写个爬虫抓取网页、处理几行CSV数据、自动化日常办公——这类代码生命周期短、逻辑简单、不需多人协作。硬套单例、工厂、观察者，反而让代码更难读。
建议：
- 优先写清楚、能跑
通、有注释的代码
- 用函数封装重复逻辑，比强行套模式更实际
- 等发现“每次加新功能都要改三处”时，再考虑重构和模式
中大型项目或团队协作，模式是沟通的共同语言
当模块变多、职责交叉、多人并行开发时，“策略模式”不只是代码结构，更是告诉同事：“这个算法可插拔，你换实现不用动调用方”。它降低理解成本，减少误改风险。
常见适用场景：
- 多个相似但行为不同的业务规则（用策略模式隔离变化）
- 对象创建逻辑复杂且可能扩展（如不同数据库连接工厂）
- 事件通知分散在各处，需要解耦（观察者模式比满屏回调清晰）
Python 的特性让部分模式变得“隐形”或不必要
动态类型、鸭子类型、函数是一等公民、装饰器、上下文管理器……这些特性天然简化了很多经典模式的实现。
例如：
- “策略”可以直接用函数或lambda传入，无需定义一堆策略类
- “装饰器模式”在 Python 里就是 @ 语法，简洁直观
- “单例”在模块级变量+懒加载就足够，不必写复杂的
__new__控制
真正该花时间的是识别“坏味道”，而不是套模式
与其纠结“这里该用模板方法还是访问者”，不如关注：函数太长？依赖太多？测试难写？修改一处引发多处bug？这些才是设计问题的信号。
建议做法：
- 先写出可测试的代码，再根据演化出的问题决定是否引入模式
- 读优秀开源库（如 requests、click、pytest）的源码，看它们怎么自然地组织逻辑
- 把模式当工具箱里的扳手——知道它存在、懂什么时候拧哪颗螺丝，而不是随身带着全套工具去散步
不复杂但容易忽略：好设计来自对问题的诚实理解，而不是对模式的熟练背诵。
