大家好，我是锋哥。今天分享关于【观察者模式和发布-订阅模式有什么异同？它们在哪些情况下会被使用？】面试题。希望对大家有帮助；
观察者模式和发布-订阅模式有什么异同？它们在哪些情况下会被使用？
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系统中，一个按钮被点击后，需要通知多个不同的监听器，使用观察者模式即可。
-
发布-订阅模式：如果你的系统中有多个消息来源和多个独立的订阅者，或者需要通过中介（如消息队列）实现异步消息传递，并且需要处理不同类型的事件或消息，发布-订阅模式会更加灵活和适用。比如在分布式系统中，各个微服务之间通过消息队列进行通信和数据同步时，通常使用发布-订阅模式。
总结：
- 观察者模式 更侧重于一个对象的状态变化需要通知多个依赖对象的场景，适合用在较为简单的事件通知机制中。
- 发布-订阅模式 更适合复杂的消息传递系统，特别是需要支持多个发布者和订阅者之间异步通信时，具有更高的扩展性和灵活性。
