# 面向对象与 GoF 设计模式

> 对应短视频主题：面向对象与 GoF 设计模式  
> 资料核验与更新：2026-09-12


用一个变化驱动的视角，串起 GoF 的 5 个创建型、7 个结构型和 11 个行为型模式，再看它们如何在真实系统中组合与复用。

## 阅读边界

本文依据原始课程的研究笔记、课程结构和发布文案整理。涉及产品、模型、版本、平台规则、价格或资格等可能变化的信息，实践前应以当前官方资料和实际环境为准。

## GoF 设计模式，真正隔离的是变化

先别背 23 个名字：先问哪一部分最可能改变。

代码一改，为什么总要牵一大片？这门课用一张图带你看懂设计模式。先把“软件设计”理解成一件事：安排代码的职责和变化边界。

GoF 是四位作者总结的二十三种经典设计模式，可以把它当成一张解决变化问题的工具地图。创建型处理对象怎么产生，结构型处理对象怎么组合，行为型处理请求、算法和职责怎么流动。

它们共同追求的不是让代码更复杂，而是让一个局部变化不要牵动整片系统。

![gof map](images/scene01_img01_gof_map.png)

图解：GoF 23 种经典设计模式全景地图：按创建型、结构型与行为型三种变化维度组织分类。

## 创建型模式：把对象产生方式隔离出来

五种模式回答的都是：谁负责创建，以及创建细节何时变化。

工厂方法 把具体产品的决定交给子类，抽象工厂 则让一整族相互匹配的产品一起创建。建造者 适合把复杂对象拆成稳定步骤，原型 通过复制已有对象减少对具体类的依赖。

单例 只解决唯一实例和统一访问这一类约束，并不意味着所有全局对象都应该单例化。

![factory](images/scene02_img01_factory.png)

图解：工厂方法与抽象工厂：将对象实例化逻辑从调用方解耦，收敛到统一的创建边界。

![builder prototype singleton](images/scene02_img02_builder_prototype_singleton.png)

图解：建造者、原型与单例模式：分别应对分步装配、对象复制与全局唯一访问三种需求。

## 结构型模式：把对象接成可替换的形状

接口、组合、职责和访问方式，都可以成为结构变化的边界。

适配器 让已有接口接入新的调用方，桥接 则把抽象与实现拆成两条可以独立变化的层次。组合 让整体和部分共享统一接口，装饰 则用包装层叠加职责而不改动核心对象。

外观 隐藏子系统复杂度，享元 共享可复用状态，代理 则在访问前加入控制或延迟。

![adapter bridge](images/scene03_img01_adapter_bridge.png)

图解：适配器与桥接模式：适配器转换不兼容接口，桥接模式使抽象与实现独立演化。

![composite decorator](images/scene03_img02_composite_decorator.png)

图解：组合与装饰器模式：在统一接口下分别支持树形整体—部分层次与动态职责叠加。

![facade flyweight proxy](images/scene03_img03_facade_flyweight_proxy.png)

图解：外观、享元与代理模式：分别用于收敛子系统入口、共享细粒度对象与控制目标访问。

## 行为型模式：重新分配请求与算法的职责

重点不再是对象长什么样，而是谁处理、谁通知、谁保存历史。

责任链让请求沿处理链寻找负责者，命令把请求封装成对象，迭代器则统一遍历方式。观察者与中介者组织对象协作，备忘录与状态处理历史和状态，策略把算法替换独立出来。

模板方法固定算法骨架，访问者外置对对象结构的操作，解释器则把规则表达成可解释的结构。

![behavior flow a](images/scene04_img01_behavior_flow_a.png)

图解：责任链、命令、迭代器、观察者与中介者：显式化对象间的消息分发、请求封装与事件通知协作。

![behavior flow b](images/scene04_img02_behavior_flow_b.png)

图解：备忘录、状态、策略、模板方法与访问者：优雅处理对象状态机、算法替换与外部数据访问。

![behavior key](images/scene04_img03_behavior_key.png)

图解：行为型模式核心归纳：按通信解耦、状态流转与算法隔离三大维度收敛选型。

## 真实系统里，模式的价值来自组合边界

一个变化轴对应一个可测试边界，多个模式可以协作但不能盲目堆叠。

以订单系统为例，策略可以替换计价规则，工厂可以扩展支付渠道，命令可以保存可撤销操作。观察者把订单状态变化通知给不同订阅者，多个模式组合后，新增一种变化不必修改所有调用方。

但如果系统根本没有替换、扩展或协作压力，模式只会增加间接层，所以复用必须和测试边界一起验证。

![composition case](images/scene05_img01_composition_case.png)

图解：真实业务案例组合：协同工厂、策略与装饰器模式应对电商订单流程的多维变化。

![composition case b](images/scene05_img02_composition_case_b.png)

图解：模式组合的边界与代价：权衡过度抽象带来的心智复杂度，保持测试与维护边界清晰。

## 选模式之前，先回答四个变化问题

把模式名放回设计现场：变化、知道、替换、成本。

看到一个新需求时，先问变化在哪里，再问谁应该知道这件事，谁应该负责它。如果需要替换算法、兼容接口、组合对象或追踪协作，模式可以提供一套共同语言。

如果引入模式后的抽象成本高于变化本身，就先保持简单，等真实压力出现再提炼。

![summary](images/scene06_img01_summary.png)

图解：设计模式选型总结：从死记硬背 23 个模式名字，回归业务变化、隔离边界与协作成本。

## 小结

把问题拆成目标、约束、证据和验证四部分，通常比直接寻找唯一答案更可靠。先用本文的框架完成一次小范围验证，再根据真实反馈调整下一步。

## 参考资料

> 📌 **查阅提示**：点击下方超链接可直接复制对应网址，粘贴至手机或电脑浏览器中即可查阅官方完整技术文档与规范。

- [【维基百科】GoF 设计模式：可复用面向对象软件的基础](https://en.wikipedia.org/wiki/Design_Patterns)  
  *说明：四人帮（Gang of Four）奠定的经典 23 种设计模式与系统复用基石。*
- [【Refactoring Guru 权威图解】设计模式通俗分类与应用图解](https://refactoring.guru/design-patterns/catalog)  
  *说明：全球知名重构与设计模式学习平台，以清晰架构图拆解各模式的优缺点与代码结构。*
- [【Refactoring Guru】什么是设计模式？软件架构中的共性问题解答](https://refactoring.guru/design-patterns/what-is-pattern)  
  *说明：阐述为什么模式不是具体算法，而是面对软件演进变化时隔离复杂度的思想工具。*
- [【O'Reilly 经典著作】《设计模式：可复用面向对象软件的基础》原书资料](https://www.oreilly.com/library/view/design-patterns-elements/0201633612/)  
  *说明：软件工程圣经级原著，系统奠定创建型、结构型与行为型三大流派。*