观察者模式中主体直接通知观察者，两者存在耦合；发布-订阅模式通过事件总线解耦发布者与订阅者。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。
最后，异步和跨模块通信的便利性。在复杂的应用中，事件往往需要跨越不同的模块，甚至可能涉及异步操作。发布-订阅模式天生就适合处理这类场景。事件总线可以很容易地集成异步处理机制（例如，将事件放入队列，稍后处理），并且它提供了一个统一的接口来管理所有事件流，这在观察者模式中，如果主体过多，就会变得非常碎片化。
所以，与其说现代框架“模仿”了发布-订阅，不如说它们在实践中自然而然地演化出了这种高度解耦的通信机制，因为这是解决复杂前端应用通信挑战的优雅之道。
选择这两种模式，在我看来，主要取决于你对耦合度和系统规模的容忍度和需求。没有绝对的优劣，只有更适合特定场景的选择。
我通常会这样考虑：
选择观察者模式的场景：
选择发布-订阅模式的场景：
我的经验是，对于小型、简单且耦合关系明确的场景，观察者模式足够用，甚至更直接。但对于复杂、大型应用，特别是需要高度模块化和解耦的前端项目，发布-订阅模式的优势会非常明显，它能有效降低系统复杂度，提升可维护性。当然，过度使用发布-订阅也可能导致事件流难以追踪，增加调试难度
以上就是JS 设计模式应用实践 - 观察者模式与发布订阅的差异与实现的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
681
收藏
