观察者模式的核心在于主题直接管理并通知观察者,而发布订阅模式通过事件中心解耦发布者与订阅者;在javascript中,该模式广泛应用于dom事件、状态管理、实时数据更新等场景,其实现需注意内存泄漏、通知性能、错误处理及数据传递方式,确保系统解耦性与健壮性。

JavaScript中实现观察者模式,核心在于构建一个“主题”(Subject)对象,它负责维护一个订阅者(Observer)列表,并在自身状态发生变化时,遍历这个列表并通知所有已注册的订阅者。说白了,就是让感兴趣的对象(观察者)去“监听”另一个对象(主题)的变化,一旦有变动,主题就会告诉它们。
class Subject {
constructor() {
this.observers = []; // 存储所有观察者
}
/**
* 添加一个观察者
* @param {Function} observer - 观察者函数或对象,通常是一个回调函数
*/
addObserver(observer) {
if (typeof observer === 'function' && !this.observers.includes(observer)) {
this.observers.push(observer);
} else {
// 我个人觉得,这里加个简单的错误提示或者日志会更好,
// 毕竟有时候传入的可能不是函数,或者重复添加了
console.warn('Observer must be a unique function.');
}
}
/**
* 移除一个观察者
* @param {Function} observer - 要移除的观察者
*/
removeObserver(observer) {
this.observers = this.observers.filter(obs => obs !== observer);
}
/**
* 通知所有观察者状态已更新
* @param {*} data - 传递给观察者的数据
*/
notify(data) {
// 有时候我会考虑是否要异步通知,避免一个耗时观察者阻塞其他,
// 但对于多数前端场景,同步通知也挺常见。
this.observers.forEach(observer => {
try {
observer(data);
} catch (error) {
// 这里捕获一下观察者执行时的错误,避免一个观察者出错导致整个通知链中断
console.error('Error notifying observer:', error);
}
});
}
}
// 示例用法:
const mySubject = new Subject();
// 定义一些观察者
const observerA = (data) => {
console.log('观察者A收到通知:', data);
};
const observerB = (data) => {
console.log('观察者B收到通知,数据是:', data);
};
const observerC = (data) => {
console.log('观察者C处理数据:', JSON.stringify(data));
};
// 注册观察者
mySubject.addObserver(observerA);
mySubject.addObserver(observerB);
mySubject.addObserver(observerC);
console.log('--- 第一次状态变化 ---');
mySubject.notify({ message: 'Hello from Subject!', timestamp: Date.now() });
// 移除一个观察者
mySubject.removeObserver(observerB);
console.log('--- 第二次状态变化(B已移除)---');
mySubject.notify('新的消息');
// 尝试添加一个非函数或重复的
mySubject.addObserver({}); // 会有警告
mySubject.addObserver(observerA); // 不会重复添加观察者模式与发布订阅模式有何不同?
这真的是一个老生常谈的问题,但它确实很重要,因为两者概念上很接近,但在实现和职责划分上有所区别。在我看来,最核心的区别在于它们之间是否存在一个“中间人”。观察者模式中,主题(Subject)是直接知道并管理着所有观察者(Observer)的。它维护一个观察者列表,并在状态改变时直接调用这些观察者的方法。这是一种“一对多”的直接依赖关系。就像一个明星(主题)直接管理着他的粉丝俱乐部(观察者),有新动态就直接发给所有粉丝。
而发布订阅模式(Pub/Sub)则引入了一个“事件中心”或“消息代理”(Broker/Event Bus)。发布者(Publisher)不直接知道订阅者(Subscriber),它只负责向事件中心发布消息;订阅者也不直接知道发布者,它只向事件中心订阅感兴趣的消息。所有的通信都通过这个中间人来完成。这就像出版社(发布者)把书交给书店(事件中心),读者(订阅者)去书店买书,出版社和读者之间并不直接打交道。
从解耦程度上看,发布订阅模式的解耦更彻底,因为它消除了发布者和订阅者之间的直接依赖。主题(发布者)和观察者(订阅者)之间完全互不干涉。这在大型应用中特别有用,可以避免组件之间形成复杂的网状依赖。观察者模式虽然也实现了观察者和主题的解耦(观察者不需要知道主题的具体实现,只需要知道它有
notify
在哪些实际场景中,观察者模式能发挥作用?
观察者模式在前端开发中简直是无处不在,只是我们可能不总用“观察者模式”这个词来称呼它。最直观的例子就是DOM事件处理。当你在一个按钮上添加
addEventListener
再比如,单页应用中的状态管理。虽然像Redux这样的库更多地被认为是发布订阅模式(因为它有一个中央的store作为事件中心),但其内部某些机制,比如组件订阅store的变化,然后根据变化重新渲染,这本质上也是一种观察行为。如果你自己实现一个简单的全局状态管理器,让组件注册监听某个状态的变化,那这就是观察者模式的典型应用。
还有一些场景,比如:
我觉得,只要是涉及到“当A发生变化时,B、C、D需要做出响应”这种需求,观察者模式就值得考虑。它提供了一种清晰、可维护的方式来处理这种一对多的依赖关系。
实现观察者模式时,有哪些常见的陷阱或优化考量?
实现观察者模式,虽然概念上简单,但在实际应用中还是有些细节需要注意,不然可能会引入一些问题。
一个比较常见的陷阱是内存泄漏。如果观察者没有被正确地从主题中移除,即使观察者本身已经不再被使用了(比如对应的DOM元素被移除了),主题仍然会持有对它的引用。这意味着垃圾回收器无法回收这个观察者,导致内存占用持续增加。这在单页应用中尤其常见,页面切换或者组件销毁时,忘记取消订阅是很要命的。所以,我的经验是,在组件生命周期结束时(比如React的
componentWillUnmount
useEffect
removeObserver
另一个是通知的顺序和性能。如果有很多观察者,或者某个观察者的回调函数执行时间很长,同步通知可能会阻塞主线程,导致UI卡顿。这时可以考虑异步通知,比如使用
setTimeout
requestAnimationFrame
Promise.resolve().then(...)
再来就是错误处理。在我的示例代码里,我加了一个
try-catch
最后,还有参数传递的考量。
notify
以上就是JS如何实现观察者模式的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号