C++ 设计模式，别死记硬背：23 种设计模式其实就这几个思路

很多人学设计模式，学着学着就会进入一种很熟悉的状态：

• 名字都听过
• 定义也背过
• 甚至类图都看过
• 但一写代码，还是不知道什么时候该用

这事其实特别正常。

因为很多人从一开始就学反了。

设计模式最不该先背的，就是定义。
你真正该先抓住的，是它背后的问题意识。

说白了，设计模式压根不是什么“高级黑话大全”，它本质上只是在回答 3 类问题：

• 对象该怎么创建，才不乱？
• 类和对象该怎么组织，才不僵？
• 一堆对象之间该怎么配合，才不炸？

你只要把这 3 个问题想明白，23 种设计模式就会一下子从“背诵题”，变成“工具箱”。

这篇文章我不按教科书那种路子讲。
不甩一堆抽象定义，不上来就给你灌术语。

咱们就按最接地气的方式聊清楚一件事：

23 种设计模式，看起来很多，其实背后就那几个思路。

如果你正在学 C++、学面向对象、学架构设计，这篇文章你可以直接收藏。
因为它不是让你死记，而是帮你把整套设计模式真正“串起来”。

一、先记这个总框架：23 种模式，本质上就分 3 大类

GoF 经典设计模式一共 23 种，但真没必要一上来就一个一个背。

你先记住下面这句话：

设计模式 = 创建型 + 结构型 + 行为型

这 3 大类，几乎已经把思路讲完了。

1. 创建型模式

它关心的核心问题是：

对象怎么创建，才更合理？

因为很多时候，问题根本不在于“能不能 new”，而在于：

• 谁来创建？
• 创建哪一种？
• 是不是只能创建一个？
• 创建过程是不是太复杂？
• 能不能别每次都从头造？

创建型模式，解决的是“对象出生这件事”。

2. 结构型模式

它关心的核心问题是：

类和对象之间，关系怎么搭，才更顺？

程序一复杂，最容易乱掉的就是结构。

• 接口对不上怎么办？
• 继承一多就爆炸怎么办？
• 一堆对象要拼成树怎么办？
• 子系统太复杂，调用太麻烦怎么办？

结构型模式，解决的是“代码骨架怎么搭”。

3. 行为型模式

它关心的核心问题是：

对象之间到底怎么协作，才不会互相拖垮？

系统复杂以后，真正难的通常不是类不够，而是对象之间关系太乱。

• 请求该交给谁？
• 一个对象变了，别人怎么知道？
• 一段逻辑里，算法怎么切？
• 一个对象状态变了，行为怎么跟着变？

行为型模式，解决的是“对象之间怎么配合”。

如果你把写程序理解成组一个团队：

• 创建型模式是在解决“人怎么招进来”
• 结构型模式是在解决“组织结构怎么搭”
• 行为型模式是在解决“团队怎么协作”

只要这个总图进脑子里了，后面 23 种模式就不再是散点了。

二、创建型模式：别只会new，对象怎么出生，本身就是设计

很多初学者有个误区：

觉得对象创建这件事特别自然，new就完了。

但项目一大你就会发现，真正容易把系统写僵的，恰恰就是“对象怎么造”。

下面这 5 种模式，都是在解决“对象出生方式”。

1. 单例模式：有些对象，全局就该只有一个

单例模式特别好理解：

一个类，全局只保留一个实例。

它适合什么场景？

比如日志器、配置中心、连接池管理器、线程池管理器。
这些东西你如果到处 new，最后状态一定乱。

你可以把它理解成公司前台。
全公司通常只需要一个前台，不会每层楼自己搞一套接待系统。

一句话记住它：

单例模式解决的是“这个对象是不是只能有一个”。

2. 工厂方法模式：别在业务里到处硬写具体类

工厂方法模式解决的是另一种常见问题：

对象别在业务逻辑里直接写死创建。

比如你要创建文档对象，有WordDocument、PdfDocument、MarkdownDocument。
如果你在业务里到处new，以后每加一种文档类型，原逻辑都要改。

工厂方法的意思就是：
“创建哪一种对象”，不要散落在业务里，而是交给工厂处理。

一句话记住它：

工厂方法模式解决的是“对象创建逻辑别写死”。

3. 抽象工厂模式：不是造一个，是造一整套

如果工厂方法是“造一个产品”，那抽象工厂就是：

一次造一整套互相配套的产品。

比如 Windows 风格按钮，要配 Windows 风格输入框；
Mac 风格按钮，也要配 Mac 风格输入框。

你肯定不想把页面拼成“按钮是 Windows 风，输入框是 Mac 风”，那看起来就像半路拼出来的。

一句话记住它：

抽象工厂模式解决的是“同一产品族怎么整套生产”。

4. 建造者模式：对象太复杂，就分步骤慢慢搭

建造者模式特别适合这种场景：

对象很复杂，不适合一个构造函数一把梭。

比如造房子，有地基、墙体、屋顶、窗户、装修。
你完全可以一步一步建，而不是把十几个参数一口气全塞进构造函数。

一句话记住它：

建造者模式解决的是“复杂对象怎么分步骤创建”。

5. 原型模式：别每次都从头造，直接复制一个现成的

原型模式的思路很像你做 PPT。

不是每一页都从空白页重新搭，
而是先复制一个模板，再改内容。

这就是原型模式的味道：

不从零造对象，直接基于已有对象克隆。

一句话记住它：

原型模式解决的是“相似对象怎么快速复制”。

创建型模式，真正想提醒你的是什么？

就一句话：

创建对象，从来不是小事。

很多系统后面为什么一改就乱？
不是因为业务逻辑本身多复杂，而是因为最开始对象创建方式就写死了。

三、结构型模式：代码能跑不算赢，关系顺不顺才是关键

写项目写到后面，最让人头疼的，往往不是“功能做不出来”，而是：

• 这个模块和那个模块怎么接？
• 这个类和那个类怎么关联？
• 想扩展一下，为什么一改就牵一串？

这时候你就会发现，结构型模式真的特别值钱。

6. 适配器模式：接口对不上，就加个翻译层

适配器模式的味道非常像插头转换器。

老设备很好，不想扔；
新插座也不能改；
那就加一个中间转换层。

在代码里也是一样：

老系统接口和新系统接口不一致，
但老代码又值得复用，
那就用适配器把它“翻译”一下。

一句话记住它：

适配器模式解决的是“接口不兼容”。

7. 桥接模式：两个维度都在变，别硬靠继承顶

桥接模式最适合处理这种情况：

有两条独立变化的线。

比如：

• 图形类型在变
• 绘制方式也在变

如果你用继承把它们硬绑在一起，类数量很快就爆炸。
桥接模式的思路就是把它们拆开，各变各的，再通过组合连起来。

一句话记住它：

桥接模式解决的是“两个维度同时变化时类爆炸”。

8. 组合模式：树形结构里，单个和整体最好统一处理

组合模式非常适合树状结构。

比如：

• 组织架构
• 文件夹结构
• 菜单系统

一个员工是节点，一个部门也是节点；
部门下面还能挂部门，还能挂员工。

组合模式的核心就是：

单个对象和对象组合，尽量用统一方式对待。

一句话记住它：

组合模式解决的是“树形结构统一处理”。

9. 装饰器模式：不改原对象，也能一层层加功能

装饰器模式是非常实战的一种模式。

比如一杯咖啡：

• 加牛奶
• 加糖
• 加巧克力

如果全靠继承，你会得到一棵越来越离谱的类树。
但如果用装饰器，你就是一层一层往外包。

一句话记住它：

装饰器模式解决的是“功能动态叠加”。

10. 外观模式：底层再复杂，对外也要好用

外观模式特别像“总控面板”。

比如你想“看电影”，但底层可能要：

• 开投影
• 切输入源
• 开音响
• 调音量
• 开播放器

如果每次都自己调一遍，调用方会烦死。
外观模式就是把这一串动作封成一个简单入口。

一句话记住它：

外观模式解决的是“复杂子系统怎么简化调用”。

11. 享元模式：能共享的，别重复造一千遍

享元模式有点像“极致省资源”。

它的核心思路是：

能共享的状态，就共享。

比如文字编辑器里的字符对象，
字符本身也许可以复用，
而字体、大小、颜色这些展示信息，可以外部传入。

一句话记住它：

享元模式解决的是“大量相似小对象怎么复用”。

12. 代理模式：不直接碰真实对象，先过我这一关

代理模式就是在真实对象前面加一个中间层。

这个中间层可以做很多事：

• 延迟加载
• 权限控制
• 缓存
• 远程调用
• 日志记录

比如图片第一次展示时再加载，这是虚拟代理；
比如只有管理员能看余额，这是保护代理。

一句话记住它：

代理模式解决的是“访问过程需要被控制”。

结构型模式，真正想提醒你的是什么？

还是一句话：

代码结构一旦搭歪，后面所有优化都会变辛苦。

很多项目不是功能做不出来，
而是结构太别扭，导致一改就连锁反应。

四、行为型模式：真正难的不是写类，而是让类别互相拖后腿

项目一开始，类少的时候，大家都挺和谐。

但一旦类多了，对象多了，逻辑复杂了，真正的麻烦才开始：

• 谁通知谁？
• 谁调用谁？
• 谁做决定？
• 状态变了怎么办？

行为型模式，解决的就是这类“协作混乱”。

13. 责任链模式：别一上来就指定处理人，让请求往后传

责任链模式就像逐级审批。

报销单先给部门经理，
不够权限再给财务，
再不够再给总经理。

调用方不需要知道最终谁处理，
只负责把请求丢到链条起点。

一句话记住它：

责任链模式解决的是“请求到底谁来接”。

14. 命令模式：把操作本身，封装成对象

命令模式的厉害之处在于：

动作不只是动作，它也可以变成对象。

这样你就能做很多事：

• 记录历史
• 撤销操作
• 重做操作
• 排队执行

比如遥控器控制灯和风扇，
按钮不直接碰设备，而是发送命令。

一句话记住它：

命令模式解决的是“操作怎么对象化”。

15. 解释器模式：规则和表达式，也能拆成对象来算

解释器模式适合简单规则系统。

比如：

• 算术表达式
• 条件规则
• 小型 DSL

它的核心就是：

把语法规则表示成对象结构，再逐层解释。

一句话记住它：

解释器模式解决的是“简单规则怎么解释执行”。

16. 迭代器模式：怎么遍历，不该暴露集合内部细节

迭代器模式其实特别常见。

它解决的是：

集合内部怎么存无所谓，但遍历方式要统一。

你只需要一个个取元素，
不需要知道底层到底是数组、链表还是别的结构。

一句话记住它：

迭代器模式解决的是“遍历逻辑和集合结构解耦”。

17. 中介者模式：对象别两两乱连，统一找协调者

中介者模式就是把“网状关系”改成“星型关系”。

最经典的例子就是聊天室。

用户不直接给所有人发消息，
而是先把消息丢给聊天室，
聊天室再统一分发。

一句话记住它：

中介者模式解决的是“多对象关系太乱”。

18. 备忘录模式：先把状态存起来，后面才能撤销

备忘录模式特别适合做撤销和回滚。

比如：

• 文本编辑器撤销
• 游戏存档
• 配置回滚

它的关键不只是“存”，而是：

在不破坏封装的前提下，把状态安全保留。

一句话记住它：

备忘录模式解决的是“状态怎么保存和恢复”。

19. 观察者模式：一个对象变了，一批对象跟着收到通知

观察者模式的本质很像订阅机制。

一个对象状态变了，
所有订阅它的人都会被通知。

比如天气站一更新天气，
所有订阅天气的客户端都自动收到消息。

一句话记住它：

观察者模式解决的是“一个变，多个跟着变”。

20. 状态模式：状态一变，行为也得跟着变

状态模式非常适合这类对象：

在不同状态下，同一个动作会有完全不同的表现。

比如自动售货机：

• 没投币
• 已投币
• 已选商品

同样是“点击按钮”，不同状态下逻辑完全不一样。

一句话记住它：

状态模式解决的是“状态不同，行为不同”。

21. 策略模式：流程不变，但算法可以随时换

策略模式是最容易落地的一种模式。

它的场景通常是：

同一个问题，有多种算法。

比如价格计算：

• 原价
• 满减
• 折扣

流程不变，
只是中间的计算方式变了。

一句话记住它：

策略模式解决的是“同一问题有多种算法可切换”。

22. 模板方法模式：流程先定死，细节再交给子类

模板方法模式特别适合这种情况：

整体流程很稳定，但中间某几步可以变化。

比如泡茶和泡咖啡：

• 烧水
• 冲泡
• 倒杯
• 加配料

大流程差不多，
但细节步骤不一样。

一句话记住它：

模板方法模式解决的是“流程不变，细节可变”。

23. 访问者模式：结构别老改，操作可以继续加

访问者模式经常出现在这种场景：

对象结构相对稳定，但你总想新增操作。

比如员工对象已经很稳定了，
但你后面还要不断加：

• 薪资统计
• 绩效分析
• 报表导出
• 审计检查

如果这些全塞回员工类里，会越来越臃肿。
访问者模式就是把这些操作外提出来。

一句话记住它：

访问者模式解决的是“结构稳定，但操作不断增加”。

行为型模式，真正想提醒你的是什么？

一句话就够：

真正让系统崩起来的，往往不是类不够，而是对象之间关系太乱。

五、别再一个个背名字了，记“问题”比记“定义”有用太多

如果你看完前面还是觉得 23 种很多，那就记下面这张“问题清单”。

以后你写代码，只要先想到问题，再去反推模式，效率会高很多。

遇到这些问题，优先想到这些模式

• 只能有一个对象：单例
• 创建逻辑不想写死：工厂方法
• 想成套创建对象：抽象工厂
• 创建过程太复杂：建造者
• 想复制现成对象：原型
• 接口不兼容：适配器
• 两个维度都在变：桥接
• 树形结构统一处理：组合
• 动态叠加功能：装饰器
• 想简化复杂系统：外观
• 大量小对象要复用：享元
• 访问需要受控：代理
• 请求逐级传递：责任链
• 操作需要记录和撤销：命令
• 规则表达式要解释：解释器
• 要遍历但不暴露内部结构：迭代器
• 多对象协调沟通：中介者
• 状态需要保存和恢复：备忘录
• 一个变多个通知：观察者
• 状态变了行为也变：状态
• 算法需要切换：策略
• 流程固定但细节可变：模板方法
• 结构稳定但操作增加：访问者

看到这里，其实你已经能发现一件事了：

设计模式并不是 23 个孤零零的名字，
而是 23 种“常见代码问题”的经典处理方式。

六、很多人学不会设计模式，不是因为难，而是因为学法不对

这里我直接说 3 个最常见的坑。

坑 1：只背定义，不看场景

这是最多人中的坑。

你把定义背得再顺，
如果不知道它解决什么麻烦，
到代码里还是不会用。

真正有效的学法是：

先看它在解决什么问题，再看它长什么结构。

坑 2：见模式就想套

设计模式不是越多越高级。

很多代码最大的问题，不是“没用模式”，
而是“问题根本没复杂到那个程度，却硬套了模式”。

一句话：

模式是为了解决问题，不是为了显得高级。

坑 3：不做模式对比

很多模式单看能懂，放一起就容易混。

比如：

• 适配器和桥接都像“中间加一层”
• 代理和装饰器都像“包一层对象”
• 状态和策略结构也很像

所以后面学习的时候，
一定要多做对比。

只学单个，不看边界，最后很容易“似懂非懂”。

七、如果你真想学会，建议按这个顺序来

别一口气从第 1 个模式读到第 23 个。

更顺的方式是分阶段：

第一阶段：先建立直觉

优先看这几个：

• 单例模式
• 工厂方法模式
• 策略模式
• 观察者模式

这几个最容易建立感觉，也最常见。

第二阶段：再理解结构

接着看：

• 适配器模式
• 桥接模式
• 组合模式
• 装饰器模式
• 外观模式
• 代理模式

这一阶段重点不是背定义，
而是体会“为什么要这么搭关系”。

第三阶段：最后理解协作

最后看：

• 责任链模式
• 命令模式
• 中介者模式
• 状态模式
• 模板方法模式
• 访问者模式

这时候你会更容易把设计模式理解成“协作方案”，而不是“类图题”。

八、完整资料我已经整理好了：能看、能跑、能下载、能分享

为了方便系统学习，我已经把这套 C++ 设计模式内容整理成了一整套专栏资料，包含：

• 23 种设计模式示例代码
• 每种模式的独立讲解文档
• 统一的CMake构建结构
• 专栏首页、总览页、文章页
• 适合继续补充和长期维护的整理方式

你可以把它当成：

• C++ 设计模式学习资料
• 面试复习资料
• 技术分享底稿
• 博客专栏素材
• 团队培训基础材料

下载入口

我用夸克网盘给你分享了「C++设计模式（代码+讲解）.7z」，点击链接或复制整段内容，打开「夸克网盘APP」即可获取。 /~5a023YUCBd~:/ 链接：https://pan.quark.cn/s/11103051338d

如果你身边刚好有人在学：

• C++
• 面向对象设计
• 设计模式
• 架构思维

你可以直接把这篇文章和整套资料转给他。

你甚至可以直接配这一句：

这是一套按 C++ 场景整理的 23 种设计模式资料，包含代码、讲解、专栏总览和文章版说明，比较适合系统入门、复习和分享。

如果你自己就在做技术公众号、博客或者知识库整理，这套东西也可以直接拿来继续扩展成系列内容。