观察者模式和发布-订阅模式有什么异同？它们在哪些情况下会被使用？

大家好，我是锋哥。今天分享关于【观察者模式和发布-订阅模式有什么异同？它们在哪些情况下会被使用？】面试题。希望对大家有帮助；

观察者模式和发布-订阅模式有什么异同？它们在哪些情况下会被使用？

1000道 互联网大厂Java工程师 精选面试题-Java资源分享网

观察者模式 (Observer Pattern) 和 发布-订阅模式 (Publish-Subscribe Pattern) 都是常见的设计模式，主要用于实现事件驱动的通信机制，通常用于解耦组件之间的依赖关系，促进松耦合的架构设计。虽然这两种模式有一些相似之处，但它们在结构、实现方式以及适用场景上有一些关键的区别。

1. 观察者模式 (Observer Pattern)

定义：

观察者模式是一种行为型设计模式，它定义了一种一对多的依赖关系，当一个对象（主题，Subject）的状态发生变化时，所有依赖于它的对象（观察者，Observer）都会被自动通知并更新。这种模式常用于实现事件驱动的系统，在某个对象的状态发生改变时，其他对象需要响应这些变化。

结构：

• Subject (主题)：被观察的对象，维护着所有依赖它的观察者。
• Observer (观察者)：依赖于Subject的对象，当Subject发生变化时，观察者会得到通知并做出相应更新。
• ConcreteSubject (具体主题)：具体的被观察者，它会通知所有的观察者。
• ConcreteObserver (具体观察者)：具体的观察者，它会对Subject的状态变化做出响应。

优点：

• 松耦合：Subject和Observer之间没有强依赖关系，Subject只需知道Observer的接口，而不关心具体的实现。
• 可扩展性强：新的观察者可以方便地加入系统中，不需要改变现有的代码。

缺点：

• 可能产生过多的更新：如果Subject状态变化频繁，可能会导致大量的通知，影响性能。
• 观察者不当管理：如果观察者没有正确地管理其生命周期（比如注销不再需要的观察者），可能会导致内存泄漏。

使用场景：

• GUI框架中的事件监听，比如按钮点击、窗口状态变化。
• MVC框架中的数据模型和视图的更新。
• 发布状态变化时通知多个不同的处理器。

---

2. 发布-订阅模式 (Publish-Subscribe Pattern)

定义：

发布-订阅模式是一种消息传递模式，它允许一个组件（发布者）将消息发布到一个消息系统（消息代理），然后其他订阅者可以订阅这些消息并接收通知。它的核心思想是“发布”和“订阅”是解耦的，发布者不知道有多少订阅者，订阅者也不关心消息的来源。

结构：

• Publisher (发布者)：消息的发布者，负责发布消息。
• Subscriber (订阅者)：消息的订阅者，接收感兴趣的消息。
• Message Broker (消息中介)：中介系统，负责将发布的消息分发给所有订阅者。发布者与订阅者之间通过这个消息中介进行间接通信。

优点：

• 松耦合：发布者和订阅者之间没有直接的依赖关系，发布者不知道有多少个订阅者，也不关心它们的具体实现。
• 灵活性高：订阅者可以根据需要选择订阅特定的消息类型，并且可以随时添加或删除订阅者。
• 异步处理：消息可以异步传递，不会直接影响发布者的执行流。

缺点：

• 消息中介的复杂性：引入了消息中介，可能增加系统的复杂性和维护成本。
• 潜在的消息丢失问题：如果没有可靠的消息传递机制，可能会出现消息丢失或延迟的问题。
• 消息顺序问题：订阅者收到消息的顺序可能无法保证，尤其在分布式系统中。

使用场景：

• 事件驱动系统，如推送通知、消息队列（例如Kafka、RabbitMQ）。
• 微服务架构中的异步通信。
• 游戏开发中的玩家事件通知、多人实时互动。
• 实时数据流和日志系统。

---

3. 异同点

特性	观察者模式 (Observer)	发布-订阅模式 (Publish-Subscribe)
耦合程度	松耦合，但Subject知道所有的Observer	松耦合，Publisher与Subscriber之间没有直接关系
依赖关系	Subject和Observer之间直接依赖	Publisher和Subscriber之间通过消息中介解耦
消息传递方式	直接通知观察者，通常是同步的	通过消息代理中介，通常是异步的
消息过滤	观察者自己决定是否响应Subject的变化	订阅者订阅特定类型的消息，可以精确过滤消息内容
使用场景	用于小范围的事件通知，适用于单一主题和观察者的场景	用于多主题和多订阅者的场景，适用于消息传递和异步处理
复杂度	较简单，通常应用于较小规模的应用程序或组件	更复杂，常用于分布式系统、大规模的消息传递系统

---

4. 选择使用观察者模式或发布-订阅模式的考虑

• 观察者模式：如果你的系统中只有一个“主题”对象需要通知多个“观察者”对象，并且这些观察者需要对该主题的状态变化做出响应，观察者模式通常更简单直接。比如在GUI系统中，一个按钮被点击后，需要通知多个不同的监听器，使用观察者模式即可。

• 发布-订阅模式：如果你的系统中有多个消息来源和多个独立的订阅者，或者需要通过中介（如消息队列）实现异步消息传递，并且需要处理不同类型的事件或消息，发布-订阅模式会更加灵活和适用。比如在分布式系统中，各个微服务之间通过消息队列进行通信和数据同步时，通常使用发布-订阅模式。

总结：

• 观察者模式 更侧重于一个对象的状态变化需要通知多个依赖对象的场景，适合用在较为简单的事件通知机制中。
• 发布-订阅模式 更适合复杂的消息传递系统，特别是需要支持多个发布者和订阅者之间异步通信时，具有更高的扩展性和灵活性。