## 01、痛点

我是老李，最近接手了一个订单系统。订单创建完成后，需要做三件事：给用户发短信、给用户加积分、扣减库存。第一版代码写得非常直观，直接在 OrderService 的 createOrder 方法里顺序调用三个服务：

```java
public void createOrder(Order order) {
    // 1. 保存订单
    orderRepository.save(order);
    // 2. 发短信
    smsService.send(order.getPhone(), "订单创建成功");
    // 3. 加积分
    pointsService.add(order.getUserId(), 100);
    // 4. 扣库存
    inventoryService.deduct(order.getSkuId(), order.getQty());
}
```

看起来没毛病。但没过多久，产品要求新增邮件通知、企业微信通知、审计日志；运营要求增加优惠券推送；财务要求增加发票开具。每次新增都在 createOrder 里加几行代码，方法从最初的 50 行膨胀到 400 多行。更要命的是，某个第三方短信服务超时导致订单创建事务回滚，用户下单失败，但短信其实已经发出去了。后来大家用 try-catch 包住每一个外部调用，结果方法里出现了 7 个 try-catch，代码彻底失控。

字符画展示失控过程：

```
OrderService.createOrder
    |
    +-- saveOrder
    +-- try { sms.send } catch { }
    +-- try { points.add } catch { }
    +-- try { inventory.deduct } catch { }
    +-- try { email.send } catch { }
    +-- try { wechat.send } catch { }
    +-- try { audit.log } catch { }
    +-- try { coupon.send } catch { }
```

到这一步，已经不是“代码写得不够高级”的问题，而是变化开始失控：新增一个动作要改核心方法，一个动作出问题可能影响订单主流程，测试时还要 mock 一堆外部服务。

> 锐评：如果只有两三个稳定依赖，硬上设计模式是过度设计；但当后续动作持续增加、并且开始影响核心业务链路时，就必须重新考虑结构了。

## 02、是什么

设计模式不是代码模板，也不是面试八股。从工程视角看，设计模式是软件开发中反复出现的一类问题的成熟解法。它有三个层次：

第一层，代码复用：避免复制粘贴相同的逻辑。

第二层，隔离变化：把可能变化的部分封装起来，不影响稳定部分。

第三层，管理复杂度：让修改半径变小，让新人能快速理解结构。

特别地，观察者模式解决的是“一对多依赖”问题：一个对象的状态发生改变时，所有依赖它的对象都得到通知并自动更新。核心角色有四个：

- Subject：抽象主题，维护观察者列表，提供注册、移除、通知方法。
- Observer：抽象观察者，定义更新接口。
- ConcreteSubject：具体主题，状态变化时通知所有观察者。
- ConcreteObserver：具体观察者，收到通知后执行自己的逻辑。

字符画表示角色关系：

```
Subject (抽象主题)
   |
   +-- addObserver(Observer)
   +-- removeObserver(Observer)
   +-- notifyObservers()
   |
   v
ConcreteSubject (具体主题，如订单服务)
   |
   +-- 变化时调用 notifyObservers()
   |
   v
Observer (抽象观察者)
   |
   +-- update()
   |
   v
ConcreteObserverA  ConcreteObserverB  ConcreteObserverC
(短信)              (积分)               (库存)
```

发布者不需要知道订阅者具体是谁，也不需要知道有多少个订阅者。它只维护一个 Observer 列表，状态变化时逐个通知。这是解耦的关键。

但要注意：模式不是公式，不是必须套用的代码模板。它是一种“职责如何拆、变化放在哪里”的思考方式。看到 if/else 按类型变化，可能想到策略模式；流程基本一样但部分步骤变化，可能想到模板方法；状态不同导致行为不同，可能想到状态模式。

## 03、为什么

很多开发者学过设计模式，却在真实项目里不会用。原因主要有三个误区。

误区一：先记模式，再找地方套。

抱着 23 种模式清单去代码里找对应场景，结果发现每个场景都能硬套一个模式，但不是每个都合适。模式是由问题驱动的，不是由模式驱动的。

误区二：看到 if/else 就认为必须上策略模式。

如果只有两个稳定分支，未来也不会增加，硬拆成策略模式只会增加类数量和阅读链路。if/else 本身不是坏味道，失控的 if/else 才是。

误区三：抽象层越多，架构越高级。

有些团队为了“可扩展”设计了五层抽象、十一个接口，结果整个项目只有两个实现类。这不是架构，这是行为艺术。

判断设计模式是否值得使用，有几个标准：

1. 变化是否真实存在？
2. 变化是否会持续增加？
3. 修改是否频繁影响旧逻辑？
4. 多个实现是否存在稳定公共结构？
5. 引入模式后，理解成本是否低于原来的维护成本？

可以给一个简单判断公式：

```
模式收益 = 未来变化成本降低 - 当前抽象复杂度增加
```

如果结果是负数，就别用。

> 锐评：十行代码解决的问题，不要写成一场架构发布会。

设计模式不是减少代码，而是降低未来修改代码的风险。它不是为了让代码看起来高级，而是为了让下一次需求变化时，你不用推倒重来。

## 04、架构

设计模式的实践地图，应该按照“开发问题”来组织，而不是按照 GoF 三大类背。比如：

- 变化类型一：对象怎么创建？——工厂 / 建造者
- 变化类型二：多个实现怎么切换？——策略
- 变化类型三：流程怎么复用？——模板方法
- 变化类型四：多个节点怎么串起来？——责任链
- 变化类型五：外部系统怎么接进来？——适配器
- 变化类型六：功能怎么动态叠加？——装饰器
- 变化类型七：状态不同怎么改变行为？——状态模式
- 变化类型八：状态变化需要通知多方，且多方可能增减？——观察者

这张图展示了从需求变化到模式选择的完整思路：

```
需求变化
   |
   v
变化点识别
   |
   v
职责拆分
   |
   v
模式选择
   |
   v
接口稳定
   |
   v
实现扩展
```

观察者模式在这一地图中的位置很明确：当一个业务动作完成后，需要在不同时间点追加多个后续动作，且这些动作可能增减，但主流程不想感知它们。

观察者模式的核心结构：

```
发布者 (ConcreteSubject)
   |
   +-- addObserver / removeObserver
   +-- notifyObservers
   |
   v
观察者列表
   |
   +-- Observer1.update()
   +-- Observer2.update()
   +-- Observer3.update()
```

这里要特别区分观察者模式和消息队列、发布订阅模式。观察者模式通常是同步的、进程内的、轻量级的，发布者直接调用观察者的方法，强调对象之间的一对多依赖。消息队列是异步的、跨进程的、重量级的，强调系统之间的解耦和削峰。发布订阅模式可以看作是观察者模式的一种分布式变体，但增加了 broker、topic、消息落地等机制。

```
观察者模式：
发布者 ---直接调用---> 观察者A
                  -> 观察者B
                  -> 观察者C

消息队列/发布订阅：
发布者 ---发送消息---> Broker ---分发---> 订阅者A
                              ---分发---> 订阅者B
                              ---分发---> 订阅者C
```

别把两者混为一谈。订单创建后的短信、积分、库存通知，如果都在同一个进程内且不需要持久化，用观察者模式就够了；如果要跨服务、削峰、保证最终一致性，再用消息队列。

## 05、实战

这一章用观察者模式重构一个真实的订单创建流程。

**一、业务场景**

订单创建成功后，需要通知多个下游：发短信、加积分、扣库存。后续可能还会增加邮件通知、企业微信通知、审计日志、优惠券推送。

**二、第一版代码**

```java
@Service
public class OrderService {
    @Autowired
    private SmsService smsService;
    @Autowired
    private PointsService pointsService;
    @Autowired
    private InventoryService inventoryService;

    @Transactional
    public void createOrder(Order order) {
        orderRepository.save(order);
        smsService.send(order.getPhone(), "订单创建成功");
        pointsService.add(order.getUserId(), 100);
        inventoryService.deduct(order.getSkuId(), order.getQty());
    }
}
```

**三、代码开始失控**

新增邮件、企业微信后，方法变成：

```java
    @Transactional
    public void createOrder(Order order) {
        orderRepository.save(order);
        try { smsService.send(...); } catch (Exception e) { log.error(...); }
        try { pointsService.add(...); } catch (Exception e) { log.error(...); }
        try { inventoryService.deduct(...); } catch (Exception e) { log.error(...); }
        try { emailService.send(...); } catch (Exception e) { log.error(...); }
        try { wechatService.send(...); } catch (Exception e) { log.error(...); }
    }
```

问题：

- 每次新增动作都要修改 createOrder 方法，违反开闭原则。
- 订单主流程与通知动作强耦合，通知异常会影响主流程或导致事务问题。
- 大量 try-catch 重复，代码可读性极差。
- 单元测试时，订单服务要 mock 所有外部服务，测试变得复杂。

**四、模式重构**

使用 Spring ApplicationEvent 实现观察者模式。

第一步，定义订单创建事件：

```java
public class OrderCreatedEvent extends ApplicationEvent {
    private final Order order;

    public OrderCreatedEvent(Object source, Order order) {
        super(source);
        this.order = order;
    }

    public Order getOrder() {
        return order;
    }
}
```

第二步，订单服务发布事件，不再直接调用下游：

```java
@Service
public class OrderService {
    @Autowired
    private ApplicationEventPublisher publisher;

    @Transactional
    public void createOrder(Order order) {
        orderRepository.save(order);
        publisher.publishEvent(new OrderCreatedEvent(this, order));
    }
}
```

第三步，实现三个监听器：

```java
@Component
public class SmsListener implements ApplicationListener<OrderCreatedEvent> {
    @Override
    public void onApplicationEvent(OrderCreatedEvent event) {
        // 发短信
    }
}

@Component
public class PointsListener implements ApplicationListener<OrderCreatedEvent> {
    @Override
    public void onApplicationEvent(OrderCreatedEvent event) {
        // 加积分
    }
}

@Component
public class InventoryListener implements ApplicationListener<OrderCreatedEvent> {
    @Override
    public void onApplicationEvent(OrderCreatedEvent event) {
        // 扣库存
    }
}
```

也可以用注解简化：

```java
@Component
public class SmsListener {
    @EventListener
    public void handleOrderCreated(OrderCreatedEvent event) {
        // 发短信
    }
}
```

**五、结构变化**

传统写法：

```
OrderService
    |
    +-- smsService.send
    +-- pointsService.add
    +-- inventoryService.deduct
```

重构后：

```
OrderService
    |
    v
ApplicationEventPublisher
    |
    v
OrderCreatedEvent
    |
    +-- SmsListener
    +-- PointsListener
    +-- InventoryListener
```

新增一个动作（比如邮件通知），只需要新建一个监听器类，不需要改 OrderService。

**六、收益**

- 订单服务与后续动作解耦，主流程只关心订单保存和事件发布。
- 新增监听器不修改原有逻辑，符合开闭原则。
- 监听器之间相互独立，可以单独测试。
- 可以结合 @Async 实现异步处理，进一步提高主流程响应速度。

异步示例：

```java
@Component
public class SmsListener {
    @Async
    @EventListener
    public void handleOrderCreated(OrderCreatedEvent event) {
        // 发短信
    }
}
```

只要在配置类上加 @EnableAsync，监听器方法就会在独立线程中执行。

**七、代价**

- 类数量增加，阅读链路变长。
- 调试时需要通过事件追踪，比直接调用更绕。
- 同步、异步语义要明确，否则可能出现事务未提交就处理事件，或事件丢失。
- 在分布式环境下，进程内事件无法跨服务，需要消息队列补足。

**八、什么时候不要用**

- 只有两三个固定且必须同步成功的依赖，且未来不会增加时，直接调用更简单。
- 所有动作必须在同一事务中严格一致时，拆成监听器会影响事务原子性。
- 动作之间的执行顺序有硬性要求时，观察者模式需要额外控制顺序，可能更复杂。

> 锐评：观察者模式不是为了让代码看起来松散，而是为了隔离“不断增加的后续动作”。如果后续动作万年不变，直接写三个方法就行，别上事件。

一句口诀：观察者模式，“不是消灭同步调用，而是让主流程不再关心后续动作”。

## 06、洞见

从“会使用观察者模式”上升到“会判断设计模式”，有几个重要洞见。

洞见一：设计模式真正关注的是“变化”，不是“类”。

不要为了凑类而创造模式。观察者模式的价值，在于隔离了“后续动作会不断增加”这个变化点。如果没有这个变化，模式就是负担。

洞见二：好的抽象通常来自重复出现的变化，而不是提前想象。

第一次遇到两个通知，不要急着重构；等到第三、第四个通知出现，且修改开始影响主流程时，抽象的价值才显现。过早抽象往往猜错变化方向。

洞见三：设计模式最重要的价值是降低修改半径。

判断一个重构是否成功，可以看一个指标：新增一个需求，需要修改几个地方。传统写法可能要改核心服务、加 try-catch、修改测试；观察者模式只需要新增一个监听器类。

洞见四：架构能力的重要体现，不是能设计多少层，而是知道什么时候不需要设计。

会加抽象是中级能力，会拒绝不必要的抽象才是高级能力。每次引入模式前，先问自己：这个变化真的会发生吗？

洞见五：很多 Spring 框架设计本身就是设计模式的大型实践。

Spring BeanFactory 是工厂模式，ApplicationListener 是观察者模式，JdbcTemplate 是模板方法，HandlerInterceptor 是责任链，AOP 是代理思想。理解这些模式，再去看 Spring 源码，会有一种“原来如此”的感觉。

> 锐评：初级开发者喜欢把代码写出来，高级开发者开始考虑怎么变化，架构师最终考虑的是：哪些地方根本不值得抽象。

## 07、行动

想真正掌握观察者模式和设计模式判断力，不要一上来背 23 种。建议分三阶段。

第一阶段：先认识 5 个最常用模式——策略、工厂、模板方法、责任链、适配器。观察者模式可以作为第六个。

第二阶段：从自己的项目里找坏味道。每天找一个：

- 大 if/else
- 重复流程
- 第三方接口污染
- 复杂对象创建
- 状态判断
- 一个动作后面跟着一串同步调用

第三阶段：尝试重构。每次重构都回答五个问题：

1. 变化点是什么？
2. 不使用模式会怎样？
3. 使用模式增加了什么复杂度？
4. 下一次新增需求，需要修改几个地方？
5. 新人是否更容易理解？

七天实践计划：

```
Day 1：找一个超过 5 个分支的 if/else。
Day 2：用策略模式重构它。
Day 3：找一段重复业务流程，尝试模板方法。
Day 4：找一个订单创建后需要通知多个下游的场景。
Day 5：用观察者模式 + ApplicationEvent 重构它。
Day 6：尝试加上 @Async 异步处理。
Day 7：重新评估：哪些重构其实没有必要？哪些代码其实直接写更清晰？
```

第七天最重要。设计模式的终极能力，是知道什么时候不用。

## 08、小结

> 设计模式不是为了让代码看起来高级，而是为了让下一次需求变化时，你不用推倒重来。

观察者模式只是 23 种模式之一，但它背后的思想适用于所有模式：看到变化，识别变化，隔离变化。

如果读完这篇文章，你少写了一个 500 行 if/else，或者少写了一个 300 行 try-catch，这篇文章就算没有白写。

## 09、链接与概念说明

**GoF 是什么？**

GoF 指 Gang of Four，即《Design Patterns: Elements of Reusable Object-Oriented Software》一书的四位作者。这本书总结了 23 种设计模式，分为创建型、结构型、行为型三大类。

**创建型 / 结构型 / 行为型分别解决什么问题？**

- 创建型：对象怎么创建更灵活，如工厂、建造者、单例。
- 结构型：类和对象如何组合成更大结构，如适配器、装饰器、代理。
- 行为型：对象之间如何协作、如何分配职责，如观察者、策略、模板方法、责任链。

观察者模式属于行为型。

**SOLID 原则与设计模式的关系**

SOLID 是五个面向对象设计原则：单一职责、开闭原则、里氏替换、接口隔离、依赖倒置。设计模式是这些原则的具体体现。观察者模式主要体现单一职责和开闭原则：发布者只负责核心逻辑，观察者各自负责自己的动作；新增观察者不修改发布者代码。

**开闭原则为什么经常和设计模式一起出现？**

开闭原则：对扩展开放，对修改关闭。它要求新增功能时尽量不修改原有代码，而是通过扩展实现。观察者模式、策略模式、装饰器模式都是这一原则的典型实现。

**推荐继续阅读**

- 《Design Patterns: Elements of Reusable Object-Oriented Software》，GoF 经典原著。
- 《Head First Design Patterns》，适合入门，案例生动。
- 《Spring in Action》，了解 Spring 事件机制和 ApplicationEvent 实践。
- Spring 官方文档中关于事件发布与监听的部分，深入理解 ApplicationContext 的事件机制。

观察者模式只是开始。真正值得学习的，不是 23 个名字，而是看到变化、识别变化、隔离变化的能力。

我是老李，最近接手了一个订单系统。订单创建完成后，需要做三件事：给用户发短信、给用户加积分、扣减库存。第一版代码写得非常直观，直接在 OrderService 的 createOrder 方法里顺序调用三个服务：

《设计模式军体拳第20招》 观察者模式 Observer——让一个变化自动通知多个对象

订单创建后通知短信、积分、库存，同步调用越写越乱。本文以 Spring 事件驱动为例，拆解观察者模式如何隔离变化，并给出使用边界。

架构师

编程语言

后端

架构设计

订单系统耦合多个通知服务导致代码膨胀、事务回滚问题频发，本文深入剖析观察者模式在订单创建场景的应用，通过Spring ApplicationEvent实现短信、积分、库存等后续动作解耦，并分享设计模式实战判断标准与重构收益，助力开发者隔离变化、降低维护成本。

消息队列

软件开发

单元测试

代码解释

短信

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《设计模式军体拳第20招》 观察者模式 Observer——让一个变化自动通知多个对象-腾讯云开发者社区-腾讯云

《设计模式军体拳第20招》观察者模式 Observer——让一个变化自动通知多个对象

《设计模式军体拳第20招》观察者模式 Observer——让一个变化自动通知多个对象

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第20招》 观察者模式 Observer——让一个变化自动通知多个对象

《设计模式军体拳第20招》 观察者模式 Observer——让一个变化自动通知多个对象

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第20招》观察者模式 Observer——让一个变化自动通知多个对象

《设计模式军体拳第20招》观察者模式 Observer——让一个变化自动通知多个对象