为什么要使用观察者模式

观察者模式（Observer Pattern）是一种行为型设计模式，它的核心思想是：

当一个对象（被观察者）的状态发生变化时，自动通知所有依赖于它的对象（观察者），并做出相应更新。

下面从为什么要用、解决什么问题、典型场景几个方面来解释。

一、为什么要用观察者模式？

1️⃣ 解耦：被观察者不依赖具体观察者

如果没有观察者模式，常见写法是：

if (stateChanged) {
    A.update();
    B.update();
    C.update();
}

问题：

• 被观察者直接依赖 A、B、C
• 新增/删除观察者要改代码
• 违背 开闭原则

✅ 使用观察者模式后：

• 被观察者只依赖“观察者接口”
• 新增观察者无需修改原有代码

2️⃣ 实现一对多的依赖关系

一个对象变化，多个对象需要响应，例如：

• 一个订单状态变化 → 通知库存、物流、消息系统
• 一个配置变化 → 通知多个模块刷新

观察者模式天然适合这种场景。

3️⃣ 支持动态注册和取消监听

观察者可以在运行时：

• 注册监听
• 取消监听

比硬编码调用更灵活。

4️⃣ 符合面向对象设计原则

• ✅ 开闭原则（对扩展开放，对修改关闭）
• ✅ 单一职责原则
• ✅ 低耦合、高内聚

二、观察者模式解决的核心问题

对象之间如何保持同步，而不紧耦合？

它解决的是：

• 状态变化如何传播
• 谁关心这个变化
• 如何通知关心的人

三、典型使用场景

✅ 1. 事件监听机制（最常见）

• GUI 框架（按钮点击、鼠标事件）
• Web 框架（监听器、钩子）

按钮(被观察者) → 点击 → 通知所有监听器(观察者)

✅ 2. 消息通知 / 发布订阅

• 消息队列
• 事件总线（EventBus）

发布者 → 事件 → 多个订阅者

✅ 3. 状态同步

• 数据模型变化 → UI 自动刷新
• 配置中心 → 各服务热更新

✅ 4. 业务解耦

例如订单系统：

订单创建
 ├─ 扣库存
 ├─ 发消息
 ├─ 记日志

订单本身不关心这些细节，只负责“通知”。

四、简单示例（Java 思想）

interface Observer {
    void update(String msg);
}

class ObserverA implements Observer {
    public void update(String msg) {
        System.out.println("A 收到：" + msg);
    }
}

class Subject {
    private List<Observer> observers = new ArrayList<>();
    private String state;

    void attach(Observer o) {
        observers.add(o);
    }

    void setState(String s) {
        this.state = s;
        notifyAllObservers();
    }

    private void notifyAllObservers() {
        for (Observer o : observers) {
            o.update(state);
        }
    }
}

五、什么时候不该用？

❌ 观察者关系非常简单
❌ 通知链复杂、容易形成循环
❌ 对性能要求极高（大量观察者）

六、一句话总结

当你需要“一个对象变化，自动通知多个对象”，并且希望它们松耦合时，就应该使用观察者模式。

如果你愿意，我也可以：

• 用 发布/订阅模型 对比讲解
• 结合 Spring 事件机制 或 Vue/React 响应式原理 讲
• 用 真实业务案例 帮你判断是否该用