设计模式终极总结
1. 模式全景回顾图
我们按照模式解决的核心问题进行分类总结：
1.1 创建型 (Creational) —— “如何优雅地创建对象？”
主要解决直接使用 new 带来的强耦合问题。
| 模式名称 | 核心口诀 | 经典实战场景 |
|---|---|---|
| 单例模式 | “天无二日”：保证全局只有一个实例。 | Redux/Vuex 的 Store，全局唯一的 Loading 弹窗。 |
| 工厂模式 | “代客下单”：隐藏 new 细节，根据参数返回对象。 | UI 组件库的动态实例化（如 Message.success()）。 |
| 构造器模式 | “批量生产”：提供对象初始化的蓝图。 | ES6 的 class 定义。 |
| 原型模式 | “克隆分裂”：基于现有对象克隆出新对象。 | JavaScript 原生继承机制的基础。 |
1.2 结构型 (Structural) —— “如何把对象组装起来？”
主要解决对象之间的依赖关系，如何让它们更好地协同工作。
| 模式名称 | 核心口诀 | 经典实战场景 |
|---|---|---|
| 代理模式 | “前台秘书”：拦截访问，代为处理。 | Vue 3 响应式原理 (Proxy)、防抖节流函数。 |
| 装饰器模式 | “手机加壳”：不改源码，动态叠加新功能。 | React 的 HOC（高阶组件）、埋点日志记录。 |
| 适配器模式 | “电源转换头”：抹平两个不兼容接口的差异。 | 兼容旧版 SDK、转换后端返回的怪异数据格式。 |
| 外观模式 | “一键全屋智能”：把复杂子系统封装成简单 API。 | jQuery 的 $.ajax（屏蔽了各种浏览器的差异）。 |
| 组合模式 | “俄罗斯套娃”：树形结构，部分和整体一致对待。 | 文件夹遍历、DOM 树渲染。 |
| 享元模式 | “共享单车”：抽取公共状态，极大节省内存。 | 长列表的虚拟滚动、对象池。 |
1.3 行为型 (Behavioral) —— “对象之间如何沟通与分配职责？”
主要解决复杂的业务流转和状态管理。
| 模式名称 | 核心口诀 | 经典实战场景 |
|---|---|---|
| 观察者模式 | “订报纸”：目标变化，自动挨个通知观察者。 | Vue 2 响应式原理 (Dep 与 Watcher)。 |
| 发布-订阅 | “中间商赚差价”：完全解耦，靠调度中心传话。 | Event Bus (全局事件总线)。 |
| 策略模式 | “锦囊妙计”：封装算法，消除 if-else。 | 表单的多重校验规则、不同 VIP 等级的计费算法。 |
| 状态模式 | “变色龙”：将复杂的状态流转拆分到不同状态类中。 | 复杂组件的各种交互状态、网络游戏人物状态。 |
| 职责链模式 | “接力赛跑”：一步步往下传，直到有人处理。 | Express/Koa 的中间件 (Middleware)。 |
| 命令模式 | “餐厅点菜单”：动作封装成对象，支持排队和撤销。 | 文本编辑器的 Undo/Redo、操作录制。 |
| 中介者模式 | “机场塔台”：多对多变一对多，集中管理交互。 | 复杂表单联动、Vuex/Redux。 |
| 迭代器模式 | “点名签到”：提供统一遍历方式。 | for...of 循环、ES6 的 Generator 生成器。 |
| 模板方法 | “考试卷子”：父类定大纲步骤，子类填具体答案。 | Vue/React 的生命周期钩子函数。 |
2. 模式设计的“六大心法” (SOLID + 迪米特)
在使用上述战术（模式）前，必须牢记这六条战略心法：
- 单一职责 (S)：一个函数/类只做一件事。
- 开闭原则 (O)：对扩展开放，对修改关闭（多用插件和策略，少改老代码）。
- 里氏替换 (L)：子类必须能完美替换父类。
- 接口隔离 (I)：不要强迫别人使用他们不需要的方法。
- 依赖倒置 (D)：依赖抽象接口，不依赖具体实现。
- 最少知识 (迪米特)：只和直接的朋友交谈，不要越级指挥。
3. 深度实战 FAQ：如何选择与权衡？
3.1 “我记不住这么多模式，怎么办？”
- 答：千万不要死记硬背名字。记住它们解决的问题。
- 看到超长的
if-else➡️ 想到策略模式。 - 看到一堆组件互相调用乱成一锅粥 ➡️ 想到中介者模式或发布-订阅。
- 想拦截别人对对象的读写 ➡️ 想到代理模式。
- 看到超长的
3.2 设计模式会降低性能吗？
- 答：通常会增加微小的 CPU 计算和内存开销（因为多了一层抽象或闭包）。但在 99% 的前端场景中，这种损耗远低于 DOM 操作带来的损耗。而它们带来的代码可读性和可维护性的提升，价值无可估量。
- 例外：享元模式专门用于提升性能。
3.3 如何避免“过度设计 (Over-engineering)”？
- 判断标准：如果你的业务逻辑一眼就能看懂，且未来几乎不会改变，直接写过程式代码！不要为了用模式而用模式，把 10 行代码写成 100 行。
- 黄金法则：当痛苦出现时（代码已经改不动了，出现坏味道了），再进行重构引入设计模式。也就是**“事不过三”原则**（同样的重复代码出现第三次时，必须重构）。
3.4 Vue/React 开发者最需要掌握哪几个？
- 代理/观察者/发布-订阅：这是理解框架响应式原理的基础。如果不懂这些，你永远只是一个 API 使用者，而不是工程师。
- 策略模式：这是日常业务开发中用来优化烂代码最锋利的刀。
- 装饰器模式：深入理解 HOC（高阶组件）的本质。