观察者与策略模式详解

本文深入剖析了观察者模式与策略模式的本质区别与实践边界：前者聚焦于“状态变更通知”，解决一对多依赖更新问题，核心在于被观察者主动推送变化给多个观察者；后者专注于“算法可插拔”，实现运行时动态切换行为逻辑，关键在于上下文对策略的解耦调用。二者职责截然不同，不可混淆或强行统一，但可在真实场景中合理组合——如报表导出用策略决定格式，同时用观察者通知进度，各司其职。文章不仅厘清概念，更直击常见误用陷阱（如内存泄漏、并发异常、过度拆分策略、状态污染等），强调设计决策应源于实际需求动因：新增的是“通知方”还是“计算方式”，才是判断模式选用的关键标尺。

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

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

它让多个观察者（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学习网公众号！