设计模式是对软件设计中反复出现的问题的通用解决方案。它们不是可以直接转化为代码的成品，而是解决特定问题的模板，描述了在特定场景下组织类与对象关系的通用策略。
设计模式的概念最早由建筑学家 Christopher Alexander 在其著作《建筑模式语言》（A Pattern Language，1977 年）中提出。Alexander 认为，在建筑设计中存在某些通用模式，这些模式描述了在特定环境下反复出现的问题及其解决方案的核心。他在书中写道：
"每个模式描述了一个在我们环境中不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能上百万次地使用该方案，而不必每次都重新设计。"
1994 年，Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides（合称 GoF，Gang of Four）将这一思想引入软件工程领域，出版了《设计模式：可复用面向对象软件的基础》一书。该书系统地归纳了 23 种设计模式，按创建型、结构型、行为型三大类组织，奠定了软件设计模式的理论基础。从此，"设计模式"成为软件工程领域的核心概念之一。
每一个设计模式都由三个基本要素构成：
| 要素 | 说明 |
|---|---|
| 模式名（Pattern Name） | 用一两个词描述模式的问题、解决方案和效果。模式名是最高层次的抽象，为开发团队提供了共享词汇。例如"策略模式"一词，远比"用可互换的算法族封装行为"更简洁高效。 |
| 问题（Problem） | 描述了在何种场景下使用该模式，即设计问题存在的前提条件。问题部分会说明模式的适用语境，包括特定的设计问题和前提条件。例如，策略模式的问题域是"需要在运行时选择不同的算法实现"。 |
| 解决方案（Solution） | 描述了设计的组成成分、它们之间的相互关系及各自的职责和协作方式。解决方案并不涉及具体实现，而是提供设计问题的抽象描述和如何用通用元素组织类与对象来解决问题。 |
三要素的关系可以理解为：模式名是标识，问题是动机，解决方案是答案。三者缺一不可，缺了问题就不知道何时使用，缺了解决方案就不知道如何使用，缺了名称就无法高效沟通。
设计模式在软件工程中的价值体现在多个层面：
架构层面：设计模式提供了一套经过验证的微观架构方案。每个模式都是对特定设计问题的成熟解答，帮助开发者在面对类似问题时不必从零开始，而是站在前人经验的基础上进行决策。这种"站在巨人的肩膀上"的方式，显著降低了架构决策的风险。
沟通层面：设计模式为开发团队提供了一套共享词汇。当一位开发者说"这里应该用工厂方法模式"时，团队中理解该模式的成员立刻知道他指的是：定义一个创建对象的接口，让子类决定实例化哪个类。这种精确的术语比长篇描述高效得多，也是 GoF 强调"模式名"作为三要素之一的原因。
教学层面：设计模式将隐性的设计经验显性化。许多资深开发者的设计直觉实际上就是对设计模式的本能运用，但这种直觉难以传授。设计模式将这些隐性知识编码为可学习、可讨论、可批判的显性知识，降低了设计能力的习得门槛。
质量层面：遵循设计模式的代码通常具有更好的内聚性、更低的耦合度、更高的可复用性和更强的可扩展性。这些质量属性并非设计模式的目的，而是良好设计的自然结果。
没有设计模式的代码往往充斥着重复逻辑。当同一段校验逻辑散落在十几个组件中时，任何一处修改都需要逐一排查所有副本。设计模式通过提取共性、封装变化，将可复用的部分抽象为稳定的结构，使得修改只需在一处进行。
可维护性的核心是降低理解成本和修改成本。设计模式通过明确的职责划分和清晰的接口契约，让每个模块的意图一目了然。当需求变化时，开发者能够快速定位需要修改的位置，而不必在纠缠的逻辑中艰难跋涉。
软件系统的需求总是在变化。新的支付方式、新的消息通道、新的数据源——这些变化是不可避免的。设计模式的核心思想之一就是"封装变化"：将变化的部分隔离出来，使得扩展新功能时不需要修改已有代码（即开闭原则）。
策略模式将算法族封装为可互换的策略对象，观察者模式将依赖关系解耦为一对多的松散通知，工厂模式将创建逻辑委托给工厂子类——这些模式从不同角度提供了应对变化的手段。
在一个没有共享词汇的团队中，沟通成本会急剧上升。考虑以下对话：
开发者 A："这个表单验证的逻辑太乱了，if-else 堆了七八层，要不我们把它拆一下？" 开发者 B："怎么拆？" 开发者 A："就是...把每种验证规则单独弄成一个对象，然后外面有个东西统一调用它们。" 开发者 B："什么意思？"
而有了共享词汇：
开发者 A："这段表单验证应该用策略模式重构。" 开发者 B："明白，每个验证规则封装为一个策略，Validator 作为 Context 持有策略引用。"
这就是 GoF 反复强调的：模式名是最重要的要素之一。一个词就能传递大量的设计信息。
下面以表单验证为例，说明没有设计模式和有设计模式时的设计差异。完整的 TypeScript 实现见 22-策略模式 的表单验证示例。
没有设计模式：if-else 堆叠
所有验证逻辑耦合在一个函数中，每新增一种验证规则都要修改这个函数，随着业务增长，函数会膨胀到难以维护。而且验证规则无法复用，无法在运行时动态替换。
有设计模式：策略模式重构
将每条验证规则封装为一个独立的策略类，新增规则只需新增一个策略实现，无需修改已有代码。验证规则可以自由组合、动态替换，并且可以在不同表单之间复用。策略模式在此场景下将"验证规则"这个变化点封装起来，满足开闭原则。
初级阶段：理解核心模式
入门阶段应优先学习使用频率最高、理解难度最低的模式，建立对设计模式的基本认知：
中级阶段：掌握模式组合与变体
在理解核心模式的基础上，扩展学习范围，关注模式之间的关系和组合使用：
高级阶段：深入理解与灵活运用
从场景出发，而非从定义出发
设计模式是解决特定问题的方案，脱离问题场景学习模式，容易陷入"知道但不会用"的困境。正确的方法是：先遇到问题，再寻找模式。例如，当你在项目中写出一段包含七八层 if-else 的表单验证代码时，再去查阅策略模式，你会获得真正的理解。
通过重构学习
在已有代码中识别"坏味道"，然后用设计模式重构，是最高效的学习方式。Martin Fowler 在《重构》中描述的许多重构手法，本质上就是向设计模式的迁移。先写出能工作的代码，再通过重构引入模式，远比一开始就套用模式更实际。
阅读框架源码
主流前端框架是设计模式的最佳实践库。Vue 3 的响应式系统使用了观察者模式和代理模式，React 的 Fiber 架构使用了职责链和状态模式，Express/Koa 的中间件机制是职责链的经典实现。阅读这些源码，可以看到设计模式在真实项目中的运用方式。
对比学习相似模式
许多模式在结构上相似但意图不同，对比学习能加深理解：
误区一：过度设计
这是最常见的问题。并非每段代码都需要设计模式。一个只有两个分支的 if-else，强行用策略模式重构，反而增加了代码的复杂度和理解成本。设计模式应该在代码确实面临扩展压力时才引入。Kent Beck 说过："Make it work, make it right, make it fast"——先让它工作，再让它正确，最后才优化。
误区二：模式迷信
设计模式不是银弹。它们是解决问题的工具，不是展示技术水平的装饰品。在简单场景下，直接的 if-else 比策略模式更清晰；在一次性脚本中，单例比依赖注入更实际。根据问题的复杂度和项目的实际需求选择方案，而非机械地套用模式。
误区三：忽视语言特性
GoF 23 种模式是针对 C++、Smalltalk 等语言总结的，JavaScript/TypeScript 拥有不同的语言特性，某些模式的实现方式需要调整：
误区四：只学不用
仅仅阅读设计模式的定义和示例代码是不够的。真正的理解来自于在项目中识别问题、选择模式、实现方案、验证效果这一完整过程。建议在日常开发中刻意练习：遇到复杂逻辑时，先分析问题，思考可以用哪种模式改善，再动手实现。
误区五：忽视重构时机
设计模式往往不是在编码初期就引入的，而是在代码演化过程中通过重构逐步引入的。过早引入模式是过度设计，过晚引入则积累技术债。关键在于识别代码的"变化点"：当某段代码频繁因同一类原因被修改时，就是引入对应模式的信号。