为什么用java观察者模式

使用 Java 观察者模式（Observer Pattern），主要是为了解决 对象之间“一对多”依赖关系下的通信和解耦问题。下面从“为什么用”的角度系统说明：

一、核心动机：解耦（最重要）

在系统中经常有这种情况：

一个对象状态变化了，其他多个对象需要知道并做出响应。

如果不用观察者模式，通常会写成：

if (stateChanged) {
    a.update();
    b.update();
    c.update();
}

问题：

• 被观察者 强依赖 观察者
• 新增/删除观察者要改代码
• 难以维护、难以扩展

✅ 观察者模式让：

• 被观察者 不知道 观察者是谁
• 只负责“通知”
• 观察者自己决定是否响应

二、典型使用场景（为什么选它）

1️⃣ 事件驱动系统

• GUI（按钮点击、鼠标移动）
• Spring 事件（ApplicationEvent）
• 消息通知

2️⃣ 状态变化广播

• 订单状态变化 → 短信、邮件、库存
• 配置变更 → 多个模块刷新

3️⃣ 数据变化同步

• Model 改变 → View 自动更新（MVC）

三、Java 中观察者模式的优势

1️⃣ 符合设计原则

• 开闭原则：新增观察者不改原代码
• 单一职责：通知 ≠ 业务逻辑
• 依赖倒置：依赖抽象（Observer）

2️⃣ Java 原生支持

• java.util.Observable（已过时但经典）
• java.util.Observer
• 现代更常用：
  • 自定义接口
  • EventListener
  • Spring ApplicationListener

四、简单示例说明“为什么好”

不用观察者（紧耦合）

class Order {
    void pay() {
        new SmsService().send();
        new EmailService().send();
    }
}

用观察者（松耦合）

interface Observer {
    void update();
}

class Order {
    List<Observer> observers = new ArrayList<>();
    void add(Observer o) { observers.add(o); }

    void pay() {
        // 只通知
        observers.forEach(Observer::update);
    }
}

✅ 新增通知方式？
➡ 只加一个 Observer，不改 Order

五、什么时候“不适合”用？

• 观察者很少、逻辑简单（过度设计）
• 强实时性、顺序严格（可用消息队列）
• 循环依赖风险（A 观察 B，B 观察 A）

六、一句话总结

用 Java 观察者模式，是为了在不修改原有代码的前提下，实现对象状态变化自动通知多个关注者，从而降低耦合、提高扩展性。

如果你愿意，我也可以：

• 用 Spring 事件机制 对比讲
• 画 UML 图
• 结合 真实业务例子（如电商、日志系统）