常用模式

---

Java 后端常用设计模式学习路线（工程实践向）

本系列文章以 Java / Spring Boot 后端工程实践 为背景，
不追求背 23 个模式，而是关注：
“在真实业务中，这个模式什么时候用、怎么用、不用会怎样”。

---

一、为什么要学设计模式

在业务初期，代码通常可以靠 if / else、直接 new 对象 解决。
但随着业务复杂度提升，会逐渐出现：

• 分支逻辑越来越多
• 新需求不断修改老代码
• 同一类逻辑散落在多个地方
• 测试困难、扩展成本高

设计模式不是为了“优雅”，而是为了“可维护、可扩展、可演进”。

---

二、学习原则

在本系列中，遵循以下原则：

1. 只讲后端真正常用的模式
2. 每个模式都给可运行的 Java Demo
3. 结合真实业务场景（如投递系统、计费、风控）
4. 强调“什么时候该用 / 不该用”

---

三、后端常用设计模式名单

第一优先级

日常开发中高频使用

模式	解决的问题	常见场景
策略模式（Strategy）	消灭 if/else	投递渠道、计费规则、风控
工厂模式（Factory）	对象创建解耦	根据类型创建实现
单例模式（Singleton）	全局唯一实例	配置、连接池
模板方法（Template Method）	流程固定、步骤不同	投递、下单、导出
责任链模式（Chain）	规则逐层校验	鉴权、限流、风控

---

第二优先

模式	解决的问题	典型应用
观察者模式（Observer）	事件解耦	Spring Event
装饰器模式（Decorator）	功能增强	AOP、日志、监控
适配器模式（Adapter）	接口不兼容	第三方 SDK
外观模式（Facade）	简化系统调用	Service / API 门面

---

第三优先级

模式	使用场景
代理模式（Proxy）	AOP、权限控制
建造者模式（Builder）	DTO 构建
组合模式（Composite）	树结构
命令模式（Command）	任务、审计

---

低优先级

• 状态模式
• 备忘录模式
• 中介者模式
• 享元模式
• 解释器模式
• 原型模式
• 访问者模式
• 桥接模式

---

四、学习顺序

01. 策略模式（Strategy）—— 如何消灭 if/else
02. 工厂模式（Factory）—— 对象创建不再混乱
03. 模板方法（Template Method）—— 固定流程的最佳实践
04. 责任链模式（Chain of Responsibility）—— 规则叠加的正确姿势
05. 单例模式（Singleton）—— Java 中真正安全的写法
06. 观察者模式（Observer）—— 事件驱动解耦
07. 装饰器模式（Decorator）—— 不改代码也能增强功能
08. 适配器模式（Adapter）—— 优雅接入第三方系统

---

五、模式组合（工程实践重点）

真实项目几乎不会“只用一个模式”

常见组合示例

策略 + 模板方法

• 使用场景：投递、支付、导出
• 作用：流程固定，细节可变

send()
 ├─ validate
 ├─ buildRequest
 ├─ doSend
 ├─ parseResponse
 └─ afterSend

---

策略 + 责任链

• 使用场景：鉴权、限流、风控
• 作用：规则逐层校验、可插拔

ApiKey → RateLimit → Balance → Send

---

外观 + 策略

• 使用场景：对外 API
• 作用：简化调用方复杂度

---

六、一个真实系统中的模式分布示例（消息推送系统）

Controller        → Facade
NotifyService     → Context
PreCheckChain     → 责任链
NotifyStrategy    → 策略
AbstractStrategy  → 模板方法
EventPublisher    → 观察者

---

七、常见误区

• 为了用模式而用模式
• 一个类里写 5 种模式
• 策略内部再写 if/else
• 把所有逻辑都塞进抽象类

模式的目标只有一个：降低未来修改成本。

---

八、结语

设计模式不是“高大上技巧”，
而是在业务复杂度不可避免增长时，让系统还能继续演进的工具箱。

本系列将以 Java + Spring Boot 实战 为主线，
逐一拆解这些模式在真实业务中的使用方式。

---

下一篇预告

策略模式（Strategy）
如何用一套可扩展结构，优雅解决 if/else 地狱。

---