设计模式：观察者模式详解与 Java 实现

2. 定义抽象观察者（Observer）

观察者接口定义了更新方法。在标准模式中通常命名为 update，此处根据业务场景命名为 priceChanged。

/**
 * 抽象观察者接口
 */
public interface Observer {
    /**
     * 当主题状态改变时被调用
     * @param subject 触发变化的主题对象
     */
    void priceChanged(Subject subject);
}

3. 具体主题实现（Concrete Subject）

具体主题持有业务数据（如价格、名称），并在数据变更时主动通知观察者。

/**
 * 具体主题：车厘子
 */
public class Cherry extends Subject {
    private long price;
    private String name;

    public Cherry(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public long getPrice() {
        return price;
    }

    /**
     * 设置价格，同时触发通知
     */
    public void setPrice(long price) {
        this.price = price;
        // 状态改变，通知所有订阅者
        notifyObservers();
    }

    @Override
    public String toString() {
        return "Cherry{" + "price=" + price + ", name='" + name + '\' + '";}';
    }
}

4. 具体观察者实现（Concrete Observer）

具体观察者实现更新逻辑，例如门店接收价格更新后打印日志。

/**
 * 具体观察者：门店
 */
public class Store implements Observer {
    private String storeName;

    public Store(String storeName) {
        this.storeName = storeName;
    }

    public String getStoreName() {
        return storeName;
    }

    public void setStoreName(String storeName) {
        this.storeName = storeName;
    }

    private void show(Subject subject) {
        System.out.println(this.storeName + " | " + subject.toString());
    }

    @Override
    public void priceChanged(Subject subject) {
        System.out.println(this.storeName);
        System.out.println("Price Changed - Refreshing price...");
        show(subject);
        System.out.println("---------------------------------------->");
    }
}

5. 测试用例

通过主函数模拟价格变动流程，验证观察者模式的动态联动效果。

/**
 * 测试类
 */
public class Demo {
    public static void main(String[] args) {
        // 创建主题
        Cherry cherry = new Cherry("车厘子");
        
        // 创建观察者
        Store one = new Store("门店一");
        Store two = new Store("门店二");

        // 订阅
        cherry.attach(one);
        cherry.attach(two);

        // 第一次价格变动
        cherry.setPrice(100);
        
        // 第二次价格变动
        cherry.setPrice(200);
        
        // 门店一退订
        cherry.detach(one);
        
        // 第三次价格变动，仅门店二收到通知
        cherry.setPrice(99);
    }
}

运行结果预期： 前两次价格变动时，门店一和门店二均会收到通知；门店一退订后，第三次变动仅门店二收到通知。

四、深度分析与注意事项

1. 线程安全性

在上述代码中，Subject 使用了 CopyOnWriteArrayList 来存储观察者列表。这是因为在多线程环境下，遍历列表的同时可能会有其他线程调用 attach 或 detach 修改列表。CopyOnWriteArrayList 保证了迭代过程中的可见性和一致性，避免了 ConcurrentModificationException。

2. 性能考量

虽然观察者模式降低了耦合度，但在高并发或观察者数量巨大的场景下，通知机制可能会成为性能瓶颈。每次状态改变都会遍历所有观察者，如果观察者执行耗时操作，会导致主题阻塞。优化方案包括：

• 异步通知：将通知放入消息队列处理。
• 批量通知：合并多次状态变更，统一通知。
• 懒加载：仅在必要时初始化观察者。

3. 常见陷阱

• 循环依赖：如果两个观察者互相依赖，可能导致死循环。应确保观察者之间无强依赖。
• 内存泄漏：如果观察者不再需要但未被注销（detach），主题仍持有其引用，导致无法回收。务必在生命周期结束时（如 Activity/Fragment 销毁）移除观察者。
• 通知顺序：默认情况下，通知顺序取决于列表插入顺序。若对顺序有严格要求，需自定义排序策略。

五、实际应用场景

在实际开发中，观察者模式的应用非常广泛。例如在 Android 购物车模块中，当商品数量变化、总价变动或库存更新时，多个 UI 组件（如底部结算栏、商品列表页）需要同步刷新。

// 简化的购物车观察者接口
public interface OnCartObserver {
    void onUpdateProduct(int position, CartProductVO product);
    void onCartClear();
    void onDeleteProduct(int position, int needUpdateCount);
}

// 业务逻辑中注册观察者
public class CartGoodsFragment extends BaseFragment {
    private final OnCartObserver onCartObserver = new OnCartObserver() {
        @Override
        public void onUpdateProduct(int position, CartProductVO product) {
            // 更新 UI 逻辑
        }
        
        @Override
        public void onCartClear() {
            // 清空 UI 逻辑
        }
        
        @Override
        public void onDeleteProduct(int position, int needUpdateCount) {
            // 删除逻辑
        }
    };

    @Override
    public void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        // 注册观察者
        XX.provideController.addObserver(onCartObserver);
    }

    @Override
    public void onDestroy() {
        super.onDestroy();
        // 移除观察者防止内存泄漏
        XX.provideController.removeObserver(onCartObserver);
    }
}

六、适用场景总结

并非所有情况都适合使用观察者模式。以下是推荐的适用条件：

1. 一对多依赖：当一个对象的改变需要通知多个对象，且这些对象之间没有明确的层级关系。
2. 动态关联：需要在运行时动态建立或解除对象间的依赖关系。
3. 低耦合需求：希望主题和观察者之间保持松耦合，便于独立扩展和维护。
4. 广播通信：类似于事件总线（Event Bus）的场景，一个事件触发多个处理逻辑。

反之，如果依赖关系复杂且嵌套深，或者通知过程涉及大量同步计算，可能需要考虑中介者模式或命令模式等其他方案。

七、结语

观察者模式是面向对象设计中最重要的模式之一。它通过解耦发布者和订阅者，提高了系统的灵活性和可维护性。然而，设计模式没有银弹，开发者应根据具体业务场景权衡利弊，避免过度设计。理解其本质——状态变更的自动传播，比生搬硬套 UML 图更为重要。