针对天气预报变化时触发用户通知和推荐行程用什么设计模式？

完整讲解（权威版）

最后更新：2026-11-01 · 基于第 1 次作答

L1 · 30 秒速记

结论：用观察者模式——天气数据作为 Subject，通知服务与行程推荐服务作为 Observer，天气变化时统一通知所有订阅者；推荐算法再用策略模式按用户/场景选择。 关键词：Observer 解耦 · Subject/Observer · Strategy 选策略 边界：观察者适合"一对多、事件驱动"；若仅单一固定反应或需强顺序强一致，观察者可能过度设计。

L2 · 核心讲解

核心考点定位：考察"事件驱动的一对多通知"选型与"算法可替换"的组合能力；面试官想看到解耦收益与失败路径，而非只背模式名。

机制链（≥3 环）：

1. 天气数据变化（Subject）→ 调用 notifyObservers() 遍历注册的 Observer → 各 Observer 的 update() 被触发 → 通知与推荐解耦。
2. 观察者在运行期动态注册/注销 → 新增通知渠道（短信/推送/行程推荐）不改天气数据类 → 符合开闭原则。
3. 推荐行程算法多变 → 用策略模式：推荐算法抽象为策略接口，运行期按用户偏好/天气场景切换 → 避免 if-else 分支爆炸。
4. 观察者回调失败 → 需异常隔离（逐 Observer try-catch）+ 重试/降级 → 防止单个观察者失败影响整条通知链路。
5. 通知链路变长/跨服务 → 从观察者演进到事件总线/消息队列 → 异步削峰、可靠投递、失败可重试 → 代价是引入中间件与最终一致。

证据锚点：

• Observer：观察者接口（update()）
• Subject：被观察者（注册表）
• notifyObservers：统一通知入口
• registerObserver / unregisterObserver：运行期订阅管理
• Strategy：算法族抽象接口
• Context：持策略引用、运行时切换
• 推模型 / 拉模型：数据传递方式
• 开闭原则：对扩展开放、对修改关闭
• 事件驱动：变化触发、被动响应
• 发布/订阅：解耦的事件模型
• 回调异常隔离：逐 Observer try-catch
• 重试 / 降级：失败兜底
• Kafka / 消息队列：跨服务异步解耦
• 死信队列：重试失败的最终兜底
• @EventListener：Spring 事件监听（观察者落地）
• ApplicationEventPublisher：Spring 事件发布入口

对比与权衡：

常见误区：

1. 错误："观察者就是回调函数" → 正确：观察者是订阅集合，回调只是实现细节；核心是"一对多、运行期动态订阅" → 为什么：回调是单点，观察者是多点注册。
2. 错误："观察者能保证通知顺序" → 正确：观察者默认不保证顺序（尤其异步），需强顺序要显式串行化 → 为什么：遍历顺序 + 异步回调打破顺序。
3. 错误："观察者回调失败要整条中断" → 正确：应逐 Observer 隔离异常 + 重试/降级，防单点拖垮通知 → 为什么：一个观察者抛异常会中断后续通知。
4. 错误："策略模式用于任何分支" → 正确：策略适合"算法族可替换"，分支少/固定用 if-else 更简单 → 为什么：过度抽象增加类数量与理解成本。
5. 错误："观察者里塞策略就完事" → 正确：观察者解决"通知谁"、策略解决"怎么推荐"，两者职责不同，应组合而非混用 → 为什么：混用会让被观察者反向依赖具体推荐算法，破坏解耦。
6. 错误："观察者只适合单机" → 正确：进程内观察者单机；跨服务可用事件总线/消息队列实现分布式观察者语义 → 为什么：网络分区、可靠投递需要中间件承载。

适用边界：

• 适合：事件源一对多、订阅者动态增删（通知/推荐/监控）。
• 不适合：仅单一固定反应；需强一致/强顺序（需显式串行化或事件总线）。
• 替代方案：事件总线（异步、跨服务）；消息队列（可靠投递、重试、死信兜底）；模板方法（骨架固定、步骤可变）；Spring 的 ApplicationEventPublisher/@EventListener 是观察者模式的框架化落地，跨服务再升级到消息队列。

延伸追问（≥3）

1. 观察者与事件总线区别？

• 要点：观察者进程内同步、事件总线可异步/跨服务
• 追问落点：何时上消息队列（可靠性、异步削峰）

1. 推模型与拉模型？

• 要点：推=Subject 传数据，拉=Observer 自行拉取
• 追问落点：各自解耦程度与空数据传递

1. 观察者回调异常怎么隔离？

• 要点：逐 Observer try-catch + 重试/降级
• 追问落点：与消息队列重试/死信队列的对比

1. 策略模式与模板方法区别？

• 要点：策略=算法整体可替换（组合）；模板=骨架固定、步骤可变（继承）
• 追问落点：何时用组合而非继承

面试者参考回答

【结论】 用观察者模式：天气数据作为被观察者，通知服务与推荐行程作为观察者，天气变化时统一通知；推荐算法再用策略模式按用户/场景选择。

【三点】

第一，观察者解耦：天气数据类不依赖具体通知渠道，新增渠道只需注册观察者，符合开闭原则。

第二，策略选算法：推荐行程算法抽象为策略接口，运行期按用户偏好/天气场景切换，避免 if-else 分支爆炸。

第三，失败隔离：逐观察者 try-catch + 重试/降级，防止单个通知失败拖垮整条链路；通知渠道在运行期动态增删，新增不改天气数据类。

【边界】 观察者适合"一对多、动态订阅"；若仅单一固定反应或需强顺序强一致，观察者可能过度设计，可改用事件总线/显式串行化；策略模式不要为少量固定分支过度抽象；链路跨服务、需可靠投递时升级到消息队列，代价是引入中间件与最终一致。

面试记录 2026-11-01（第 1 次）

题目：天气预报变化触发用户通知和推荐行程，用什么设计模式？

难度：high

标签：design-pattern/observer, design-pattern/strategy, general/knowledge, difficulty/high

评分：⭐⭐⭐⭐☆（4/5）

我的回答

天气预报变化可以做一个观察者模式,观察天气预报的变动,如果有变动就触发下一阶段执行的操作,对应设定一个策略模式,对不同的添加推送不同的行程

点评

评分：⭐⭐⭐⭐☆（4/5）

优点：正确定位观察者模式（天气变化 → 触发下游通知/推荐）+ 策略模式（对不同场景选不同推送/行程）。选型正确、有组合意识。

不足：没展开解耦收益（天气源与通知/推荐解耦，增删观察者不动源）、观察者的推/拉模型、策略与模板方法/简单工厂的区别、以及"什么时候观察者会过度设计"。

补充：补①观察者的解耦与开闭原则；②推/拉模型；③回调异常隔离与重试降级；④策略 vs 模板方法；⑤过度设计的边界。

完整讲解见上方「完整讲解（权威版）」