观察者与策略模式详解

本文深入剖析了观察者模式与策略模式的本质区别与实践边界：前者聚焦于“状态变更通知”，解决一对多依赖更新问题，核心在于被观察者主动广播变化、观察者被动响应；后者致力于“算法可插拔”，应对行为逻辑的动态切换，核心是上下文与具体算法解耦、运行时灵活替换。二者职责截然不同——一个管“谁要知情”，一个管“怎么做”，虽可协同使用（如报表导出用策略选格式、用观察者推进度），但绝不能混淆或强行统一。文章直击常见误区：内存泄漏、并发异常、策略污染、过度拆分等，并强调设计判断的关键不在于套用术语，而在于敏锐识别需求本质——新增的是“通知方”还是“计算方式”？真正考验程序员功力的，永远是代码现场的动因洞察。

观察者模式和策略模式解决的是两类完全不同的问题：前者关注对象间的一对多依赖更新，后者聚焦于算法的动态替换。混用或强行统一理解，反而会模糊各自的设计意图。

观察者模式的核心是「状态变更通知」

它让多个观察者（Observer）能自动响应被观察者（Subject）的状态变化，典型场景是事件驱动、MVC 中的视图刷新、发布-订阅系统。

• 关键不是“谁调用谁”，而是“谁被通知”——Subject 持有 List，在 notifyObservers() 中遍历调用每个 update()
• Java 标准库曾提供 java.util.Observable 和 java.util.Observer，但自 JDK 9 起已标记为 @Deprecated，不推荐使用；应优先手写接口或采用 java.util.concurrent.CopyOnWriteArrayList 管理观察者列表，避免并发修改异常
• 容易踩的坑：观察者未及时 remove() 导致内存泄漏；notify 过程中修改观察者列表引发 ConcurrentModificationException

策略模式的核心是「算法可插拔」

它把一组行为（算法）封装成独立类，通过统一接口（如 Strategy）注入到上下文（Context）中，在运行时切换逻辑，典型场景是支付方式选择、排序策略、文本渲染规则。

• Context 不关心具体怎么算，只持有一个 Strategy 引用，并在需要时调用 execute() 或 calculate() 等方法
• 策略类之间必须「无状态」或「状态可控」，否则在多线程中共享同一实例可能引发数据污染；若需保存上下文数据，应将参数显式传入方法，而非依赖成员变量
• 常见误用：把简单 if-else 拆成一堆空策略类，反而增加维护成本；策略类之间存在强依赖或需要协同执行时，说明它已超出策略模式适用边界

二者组合使用的现实约束

可以一起用，但不能为了设计而硬套。比如一个报表生成器（Context）用策略决定导出格式（PDF/Excel），同时用观察者通知 UI 进度更新——此时策略管“怎么做”，观察者管“谁要知情”，职责清晰。

• 不要让策略类直接实现 Observer 接口，除非该策略本身职责就包含响应外部事件；否则会混淆“算法”与“反馈”的边界
• 观察者收到通知后，如果要触发不同策略，应在观察者内部构造或获取对应 Strategy 实例，而不是由 Subject 持有策略引用并代为分发
• Spring 中可用 @EventListener 替代手动注册观察者，用 @Qualifier + 接口注入区分策略实现，但底层仍是这两套机制的自然延伸，不是抽象升级

真正难的从来不是记住定义，而是在需求变动时判断：这次加的是「新通知方」，还是「新计算方式」——名字可以查文档，动因得靠代码现场说话。

终于介绍完啦！小伙伴们，这篇关于《观察者与策略模式详解》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！