文章目录
-
- [1. 设计模式不是"都要用"，而是"在合适的时候用"](#1. 设计模式不是“都要用”，而是“在合适的时候用”)
- [2. 创建型模式（5 种）](#2. 创建型模式（5 种）)
- [3. 结构型模式（7 种）](#3. 结构型模式（7 种）)
- [4. 行为型模式（11 种）](#4. 行为型模式（11 种）)
-
- [4.1 非常常用（必须掌握）](#4.1 非常常用（必须掌握）)
- [4.2 常用（理解 + 会用）](#4.2 常用（理解 + 会用）)
- [4.3 不常用（理解思想即可）](#4.3 不常用（理解思想即可）)
- [5. 为什么有些模式"几乎用不到"？](#5. 为什么有些模式“几乎用不到”？)
- [6. 学设计模式的正确姿势](#6. 学设计模式的正确姿势)
1. 设计模式不是"都要用"，而是"在合适的时候用"
先说一个结论：
设计模式不是语法，而是经验。
- 它们不是框架
- 不是 API
- 更不是"代码模板"
而是对常见问题的高质量解法抽象。
2. 创建型模式（5 种）
| 模式 | 常用程度 | 工程评价 |
|---|---|---|
| 单例模式 | ⭐⭐⭐⭐⭐ | 几乎人人都用，但也最容易被滥用 |
| 工厂方法模式 | ⭐⭐⭐⭐⭐ | Spring 的核心思想之一 |
| 抽象工厂模式 | ⭐⭐⭐ | 框架层常用，业务层较少 |
| 建造者模式 | ⭐⭐⭐⭐ | 构建复杂对象非常实用 |
| 原型模式 | ⭐⭐ | 用得不多，但思想常见（clone） |
3. 结构型模式（7 种）
| 模式 | 常用程度 | 工程评价 |
|---|---|---|
| 代理模式 | ⭐⭐⭐⭐⭐ | Spring AOP、RPC 核心 |
| 装饰者模式 | ⭐⭐⭐⭐⭐ | I/O 流、功能增强利器 |
| 适配器模式 | ⭐⭐⭐⭐⭐ | 接口不兼容的万能解法 |
| 外观模式 | ⭐⭐⭐⭐ | 降低系统使用复杂度 |
| 桥接模式 | ⭐⭐⭐ | 框架中常见，业务中偏少 |
| 组合模式 | ⭐⭐ | 树形结构场景专用 |
| 享元模式 | ⭐⭐ | 高性能/内存优化场景 |
4. 行为型模式（11 种）
4.1 非常常用（必须掌握）
| 模式 | 评价 |
|---|---|
| 策略模式 | 消除 if-else 的第一利器 |
| 模板方法模式 | 框架设计必备 |
| 责任链模式 | Filter / 拦截器 / Pipeline |
| 观察者模式 | 事件驱动、消息机制 |
4.2 常用（理解 + 会用）
| 模式 | 评价 |
|---|---|
| 命令模式 | 操作封装、支持撤销 |
| 状态模式 | 状态驱动行为，替代复杂条件 |
| 中介者模式 | 多对象交互解耦 |
| 迭代器模式 | 几乎每天都在用（Iterator） |
4.3 不常用（理解思想即可）
| 模式 | 评价 |
|---|---|
| 访问者模式 | 学术性强，编译器/AST 常用 |
| 备忘录模式 | 撤销/回滚场景专用 |
| 解释器模式 | DSL/规则引擎，工程中少见 |
5. 为什么有些模式"几乎用不到"？
原因主要有三点：
框架已经替你用了
例如：
- 迭代器（JDK）
- 代理（Spring）
- 工厂（Spring / MyBatis）
业务复杂度不够
像：
- 访问者
- 解释器
更适合语言处理 / 编译器 / 规则系统。
有更简单的替代方案
例如：
- Lambda + Strategy
- Stream + Iterator
- 配置化 + if-else（有时更清晰）
6. 学设计模式的正确姿势
❌ 错误姿势：
- 背 UML
- 强行套模式
- 为用而用
✅ 正确姿势：
- 先写"丑代码"
- 感受到痛点
- 再引入模式
- 理解权衡