设计模式系列——观察者模式
内容提要
观察者模式是一种订阅机制，允许多个观察者在可观察对象发生变化时接收通知。发布者筛选订阅者并发布更新，适用于商品降价通知、库存更新等场景。观察者需定义更新方法以处理通知参数。该模式的优点是代码解耦，但也存在隐式依赖和性能瓶颈等缺点。
延伸解读
观察者模式与消息队列的适用边界
文章指出，观察者模式是一种通用的订阅机制，适用于非使命必达的场景，而Kafka、Redis、RabbitMQ等消息队列则更适合需要可靠投递的场景。这意味着在系统设计时，若业务允许通知丢失或延迟，且希望减少外部依赖，观察者模式是更轻量的选择；反之，若要求高可靠、持久化或跨服务通信，则应考虑消息队列。
订阅类型与通知筛选的实际意义
案例中，商品可观察对象根据订阅类型（来货通知、降价通知、降价到预期通知）筛选观察者，仅当条件满足时才调用update。这体现了观察者模式的核心优势：发布者无需关心具体订阅者，只需按规则分发。实际开发中，这种筛选逻辑可避免无效通知，提升效率，但也要求发布者维护订阅者的状态信息。
Spring事件监听对观察者模式的简化
文章对比了Spring的EventListener机制，它通过ApplicationEventPublisher发布事件，由Listener处理，省去了手动维护观察者列表和调用update的步骤。这降低了代码侵入性，但底层仍是观察者模式。开发者需注意，Spring事件默认同步执行，若监听器耗时较长，可能阻塞主流程，可结合@Async异步处理。
隐式依赖与性能风险的应对思路
文章总结的缺点包括隐式依赖、瞬时峰值和并发问题。隐式依赖使系统行为难以预测，需通过文档和日志弥补；瞬时峰值可能因大量订阅者同时更新导致性能瓶颈，可引入异步或削峰；并发问题则需使用线程安全集合、显式锁或原子操作。这些提醒开发者在采用观察者模式时，需权衡解耦带来的灵活性与潜在维护成本。
Q&A
观察者模式的基本定义是什么？
观察者模式是一种订阅机制，允许多个观察者在可观察对象发生变化时接收通知。
观察者模式适用于哪些场景？
观察者模式适用于商品降价通知、库存更新等场景。
观察者模式的优点和缺点分别是什么？
优点是代码解耦，缺点包括隐式依赖、性能瓶颈和并发问题。
观察者需要实现哪些方法来处理通知？
观察者需定义更新方法以处理发布者的通知参数。
如何在观察者模式中实现订阅和取消订阅？
可观察对象提供subscribe和unsubscribe方法来实现订阅和取消订阅。
观察者模式在多线程环境中可能遇到什么问题？
在多线程中，事件的发布和订阅者的变动可能导致并发问题，需要复杂的同步机制来确保线程安全。
