概述
设计模式是一种对可重复软件设计经验的结构化表达方式，用于解决在特定上下文中反复出现的问题。 它既是一种代码组织思想，也是一种团队共同的 沟通语言、认知工具与架构思维框架。
设计模式的价值不在于具体类图或代码技巧，而在于：
- 对"何时、为何、如何抽象"的共识
- 对复杂度与灵活性的权衡能力
- 对软件演进方向和变更来源的理解
设计模式不是编写代码前的模板，而是在项目不断演进中沉淀的结构认知。
本质
一个设计模式的存在必须同时满足三点本质特征：
- 重复性（Repetition）：是对反复出现的问题或结构的提炼
- 可沟通性（Communication）：模式必须具有命名和传达价值
- 稳定的结构（Structure）：包含通用角色和组织方式，可用于系统复用
换言之：
设计模式是"可命名的、可复述的、可复用的软件结构化经验"。
它是介于"设计原则"和"具体架构"之间的中观层抽象。
模式的结构化表达模型
为了使模式具备标准化和可复用性，一个成熟的设计模式通常包含以下五个核心元素：
- 名称（Name）：用于沟通，是最关键的元素
- 意图（Intent）：解决什么问题，如何优雅地解决
- 结构（Structure）：角色、职责、协作方式，可用类图或关系描述
- 适用性（Applicability）：在哪些场景下使用/不使用
- 后果（Consequences）：优点、限制、代价
这个模板为团队形成与评审设计模式提供统一规范。
设计模式的关键属性
设计模式不是单纯的"解决方案"，而是一类具有明确属性的工程经验。 高质量的设计模式应具备以下五个通用属性：
可命名性
必须能用一个简洁的名称表达核心意图。 命名是模式存在的前提。
可复述性
必须在多个系统或上下文中出现，具有通用性。
可沟通性
设计模式本质上是沟通语言。 一句"用 X 模式"即可传递大量隐含结构信息。
可复用性
模式的结构在逻辑层面可重用，甚至可以跨语言、跨框架。
可演化性
优秀模式可随着技术变化而演化，不是固定不变的代码模板。
模式的边界与误区
设计模式不是银弹，也不是必须使用的工具。错误使用会带来反效果。
模式的边界
- 不是微观代码技巧（那是 idiom）
- 不是框架级架构（那是 architecture）
- 不直接带来性能收益（主要提升结构弹性）
- 不适用于一次性系统
- 不应强行加入没有变化来源的模块
常见误区
- 为用模式而用模式（Over-Engineering）
- 抽象过度
- 管理层强制要求"所有模块都用模式"
- 将模式理解成类图模板
模式与设计原则、架构的关系模型
设计模式是一个位于 设计原则与系统架构之间的中观层结构工具。
可以用如下抽象模型表示：
设计原则（Why） → 设计模式（How） → 项目架构（What）
设计原则
- 是思想
- 抽象且稳定
- 指导如何做"好的软件设计"
- 如 SRP、DIP 等
设计模式
- 是将原则结构化后的可复用形式
- 是对变化来源的应对方式
架构
- 是使用多个模式组合构成的系统结构
- 与业务、规模、技术栈相关
- 模式是构建架构的基础粒度
模式不是架构，但架构离不开模式。
设计模式的演化规律
设计模式不是静态资产，而是长期演进产物。 其生命周期可分为：
- 发现（Emergence）：在多个系统中观察到重复结构
- 抽象（Abstraction）：提炼出共同角色和协作方式
- 命名（Naming）：形成可沟通语言
- 验证（Validation）：跨项目使用并稳定下来
- 泛化（Generalization）：适用于更广场景，提升抽象度
- 成熟（Maturation）：成为团队共识
- 弃用（Deprecation）：随着技术变迁被更优方案取代
例如随着 FP、协程、响应式流的兴起，一些传统 OO 模式已经弱化或演化。
如何发现与沉淀模式
设计模式不是学习来的，而是"抽象出来"的。 以下是团队挖掘新模式的流程建议：
识别重复问题
- 多个项目出现相同痛点
- 多个模块在对付同类变化源
提炼结构共性
- 抽象角色
- 划分职责
- 找到稳定点与变化点
命名
名称应准确、简洁、具有认知统一性。
结构化表达
按照 Pattern Schema 写成规范文档。
评审
邀请团队讨论，优化边界与适用性。
归档到模式库
形成团队知识资产。
反模式
反模式是"看似优雅但在大多数情况下反而造成问题"的重复做法。
识别反模式的关键指标：
- 复杂度高于收益
- 过度抽象导致可读性下降
- 扩展性被误解为必须灵活
- 忽略性能、可维护性、一致性
- 仅为迎合某模式而重构
模式的价值体系总结
设计模式的核心价值可以概括为：
- 可沟通性：团队沟通成本降低
- 可复用性：减少重复设计
- 可维护性：提升结构清晰度与可扩展性
- 可预测性：降低新人上手成本
- 可演化性：让系统在变化中保持稳定
设计模式是一种组织复杂软件的结构化认知，是在变化中寻求稳定的工具。