观察者与策略模式详解

目前golang学习网上已经有很多关于文章的文章了，自己在初次阅读这些文章中，也见识到了很多学习思路；那么本文《观察者与策略模式核心解析》，也希望能帮助到大家，如果阅读完后真的对你学习文章有帮助，欢迎动动手指，评论留言并分享~

观察者模式解决对象间一对多依赖更新，核心是状态变更通知；策略模式解决算法动态替换，核心是算法可插拔。二者职责分明，可组合使用但不可混淆边界。

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

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

它让多个观察者（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学习网公众号，带你了解更多关于的知识点！