观察者模式中主体直接通知观察者，两者存在耦合；发布-订阅模式通过事件总线解耦发布者与订阅者。1. 观察者模式：主体维护观察者列表并主动调用其更新方法，适用于关系明确、局部通信的场景。2. 发布-订阅模式：引入事件总线作为中间人，发布者与订阅者仅与总线交互，实现完全解耦，适合跨模块、全局通信。3. 现代前端框架如React、Vue的状态管理采用发布-订阅思想，因组件化架构需扁平化通信、异步处理和高解耦。4. 选择依据：若对象间关系紧密且范围小，选观察者模式；若需高度解耦、跨模块通信或未来扩展性强，选发布-订阅模式。5. 发布-订阅虽提升灵活性，但过度使用可能导致事件流混乱、调试困难。
在JavaScript中，观察者模式（Observer Pattern）和发布-订阅模式（Publish-Subscribe Pattern）都是实现对象间一对多通信的有效方式，但它们在解耦程度和实现机制上存在显著差异。核心观点是：观察者模式中，主体（Subject）直接管理并通知它的观察者（Observer），两者之间存在直接的引用关系；而发布-订阅模式则引入了一个中间的事件调度中心（Event Bus/Broker），发布者（Publisher）和订阅者（Subscriber）都只与这个中心交互，彼此之间完全解耦。
解决方案
在我看来，理解这两种模式的关键在于“谁知道谁”。在观察者模式里，主体是“知道”它的观察者的，它维护着一个观察者列表，并在自身状态变化时，遍历这个列表并直接调用观察者的更新方法。这就像一个明星（主体）直接告诉他的粉丝团（观察者）他的最新动态。
// 观察者模式：主体直接管理观察者class Subject { constructor() { this.observers = []; // 主体知道所有观察者 } addObserver(observer) { this.observers.push(observer); } removeObserver(observer) { this.observers = this.observers.filter(obs => obs !== observer); } notify(data) { console.log("Subject: My state changed, notifying observers..."); this.observers.forEach(observer => observer.update(data)); }}class Observer { constructor(name) { this.name = name; } update(data) { console.log(`${this.name}: Received update - ${data}`); }}// 使用const mySubject = new Subject();const obsA = new Observer('Observer A');const obsB = new Observer('Observer B');mySubject.addObserver(obsA);mySubject.addObserver(obsB);mySubject.notify('New data available!');// Output:// Subject: My state changed, notifying observers...// Observer A: Received update - New data available!// Observer B: Received update - New data available!
而发布-订阅模式则完全不同。它引入了一个“中间人”——事件总线（Event Bus）或消息代理（Message Broker）。发布者仅仅向这个中间人发布某个“主题”的事件，它根本不知道谁会订阅这个主题。同样，订阅者也只是向中间人订阅它感兴趣的“主题”，它也不知道是哪个发布者发布了这些事件。这就像一个公告板（事件总线），有人在上面贴通知（发布），有人去看自己感兴趣的通知（订阅），发通知的和看通知的彼此不认识。
// 发布-订阅模式：通过事件总线解耦发布者和订阅者class EventBus { constructor() { this.subscribers = {}; // topic: [callbacks] } subscribe(topic, callback) { if (!this.subscribers[topic]) { this.subscribers[topic] = []; } this.subscribers[topic].push(callback); // 返回一个取消订阅的函数，便于管理 return () => { this.subscribers[topic] = this.subscribers[topic].filter(cb => cb !== callback); }; } publish(topic, data) { if (this.subscribers[topic]) { console.log(`EventBus: Publishing topic "${topic}" with data:`, data); this.subscribers[topic].forEach(callback => { try { callback(data); } catch (error) { console.error(`Error in subscriber for topic "${topic}":`, error); } }); } }}// 使用const globalEventBus = new EventBus();// 订阅者const unsubscribeLogger = globalEventBus.subscribe('userLoggedIn', (userData) => { console.log(`Logger Service: User ${userData.username} logged in.`);});const unsubscribeWelcome = globalEventBus.subscribe('userLoggedIn', (userData) => { console.log(`Welcome Message: Hello, ${userData.username}!`);});// 发布者function simulateLogin(user) { console.log(`Simulating login for ${user.username}...`); globalEventBus.publish('userLoggedIn', user);}simulateLogin({ userId: 1, username: 'Alice' });// Output:// Simulating login for Alice...// EventBus: Publishing topic "userLoggedIn" with data: { userId: 1, username: 'Alice' }// Logger Service: User Alice logged in.// Welcome Message: Hello, Alice!unsubscribeLogger(); // 移除日志服务的订阅simulateLogin({ userId: 2, username: 'Bob' });// Output:// Simulating login for Bob...// EventBus: Publishing topic "userLoggedIn" with data: { userId: 2, username: 'Bob' }// Welcome Message: Hello, Bob!
从代码层面看，最大的区别就是那个
EventBus
。观察者模式里，
Subject
承担了
EventBus
的部分职责，它直接维护了订阅列表。而发布-订阅模式则把这个职责抽离成了一个独立的模块。这种分离带来的就是更高的解耦度。
为什么在现代前端框架中，我们更多地看到类似发布订阅的模式？
这确实是一个很有意思的现象。现代前端框架，如React（通过Context API、Redux/MobX等状态管理库）、Vue（通过Vuex/Pinia等状态管理库，或早期的EventBus模式），它们在组件间通信和状态管理上，都大量借鉴了发布-订阅的思想。究其原因，我认为主要有以下几点：
首先是组件化架构的必然选择。在大型前端应用中，组件树可能非常深，层级复杂。如果采用传统的观察者模式，一个深层嵌套的子组件要通知一个远方的兄弟组件或祖先组件，就需要通过props一层层传递回调函数（props drilling），或者直接引用（这会造成紧耦合）。这很快就会变得难以维护和理解。发布-订阅模式提供了一个“扁平化”的通信渠道，任何组件都可以发布事件，任何组件都可以订阅事件，只要它们约定好事件的“主题”，就可以进行通信，而无需知道彼此的具体位置和引用。
其次是实现真正的解耦和模块化。发布-订阅模式让发布者和订阅者之间没有任何直接依赖。这意味着你可以独立开发、测试和部署不同的模块或组件，只要它们遵守相同的事件协议。一个组件可以发布一个事件，即使当前没有任何订阅者，它也能正常工作。未来如果需要新的功能来响应这个事件，只需要添加一个新的订阅者即可，而无需修改发布者。这种高度解耦对于大型团队协作和长期项目维护至关重要。
再者，状态管理的需求。像Redux、Vuex这样的状态管理库，其核心机制就是发布-订阅模式的变体。当应用的状态（store）发生变化时，它会通知所有订阅了这些状态变化的组件进行更新。组件不需要直接“观察”store，而是通过连接器（connect）或hooks向store“订阅”变化，store则作为发布者，在状态更新时“发布”通知。这使得状态变化可预测、可追溯，并且能高效地更新UI。
最后，异步和跨模块通信的便利性。在复杂的应用中，事件往往需要跨越不同的模块，甚至可能涉及异步操作。发布-订阅模式天生就适合处理这类场景。事件总线可以很容易地集成异步处理机制（例如，将事件放入队列，稍后处理），并且它提供了一个统一的接口来管理所有事件流，这在观察者模式中，如果主体过多，就会变得非常碎片化。
所以，与其说现代框架“模仿”了发布-订阅，不如说它们在实践中自然而然地演化出了这种高度解耦的通信机制，因为这是解决复杂前端应用通信挑战的优雅之道。
如何选择：观察者模式还是发布订阅模式？
选择这两种模式，在我看来，主要取决于你对耦合度和系统规模的容忍度和需求。没有绝对的优劣，只有更适合特定场景的选择。
我通常会这样考虑：
选择观察者模式的场景：
紧密耦合且关系明确的一对多关系： 如果你有一个明确的“主体”对象，它直接拥有并管理它的“观察者”列表，并且主体和观察者之间的关系是直接且强烈的，那么观察者模式可能更合适。例如，一个数据模型（Subject）需要通知所有直接依赖它的UI组件（Observer）进行更新。主体明确知道谁在观察它。小范围、局部性的通信： 当通信范围仅限于少数几个对象之间，且这些对象都在同一个模块或组件的紧密控制之下时，观察者模式的实现会更简单、更直接，开销也更小。同步通知是预期行为： 观察者模式通常意味着主体状态变化后，会立即、同步地通知所有观察者。如果这是你希望的行为，那么它很合适。示例：DOM元素上的事件监听器：一个按钮（Subject）直接管理它的点击处理函数（Observer）。一个自定义表单控件（Subject）通知其父级表单（Observer）其值已更改。
选择发布-订阅模式的场景：
高度解耦是首要目标： 如果你希望发布者和订阅者之间完全不知道彼此的存在，只通过一个中间人进行通信，那么发布-订阅模式是理想选择。这对于构建可插拔、可扩展的系统至关重要。跨模块、全局性的通信： 当事件需要跨越整个应用程序的不同部分，或者在完全不相关的组件之间进行通信时，一个全局的事件总线能提供一个统一、清晰的通信渠道。异步处理事件的需求： 虽然发布-订阅模式本身不强制异步，但事件总线更容易集成异步处理机制（例如，将事件推入队列，稍后处理），这对于处理耗时操作或避免UI阻塞非常有用。未来扩展性考虑： 如果你预计未来会有新的功能需要响应现有事件，或者新的模块需要发布事件，而不想修改现有代码，发布-订阅模式能提供更大的灵活性。示例：用户登录后，需要通知导航栏更新、分析服务记录、欢迎消息显示等多个不相关的模块。一个第三方插件发布特定事件，而你的应用可以订阅这些事件来扩展功能。大型单页应用中的状态管理，如Redux或Vuex，它们通过发布-订阅机制通知组件状态变化。
我的经验是，对于小型、简单且耦合关系明确的场景，观察者模式足够用，甚至更直接。但对于复杂、大型应用，特别是需要高度模块化和解耦的前端项目，发布-订阅模式的优势会非常明显，它能有效降低系统复杂度，提升可维护性。当然，过度使用发布-订阅也可能导致事件流难以追踪，增加调试难度
以上就是JS 设计模式应用实践 – 观察者模式与发布订阅的差异与实现的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1521943.html
微信扫一扫 
支付宝扫一扫 
