在Node中,要实现观察者模式非常的简单,而且内置于EventEmitter
类中,EventEmitter
类允许我们注册一个或者多个函数作为监听者,当对应的事件触发后,它们就会被触发
EventEmitter
是一个原型,可以通过events这个核心模块获取得到
const EventEmitter = require('events').EventEmitter;
const eventEmitter = new EventEmitter();
EventEmitter
内部提供了几个API
-
on(event, listener)
注册监听者 -
once(event, listener)
注册监听者,但是只会触发一次 -
emit(event, [arg1], [...])
发布一个事件 -
removeListener(event, listener)
移除监听者
上面的方法都支持链式调用。而且我们会发现listener和我们所知道的传统的Node回调函数是不同的,最突出的就是函数的第一个参数不是error,而是我们emit时候穿过去的参数
使用EventEmitter
使用它最简单的方式就是去创建一个新的实例,然后立刻使用它
const EventEmitter = require('events').EventEmitter;
const fs = require('fs');
function findPattern(files, regex) {
const emitter = new EventEmitter();
files.forEach((file, index) => {
fs.readFile(file, (err, content) => {
if(err) {
emitter.emit('error', err);
}
emitter.emit('fileRead', file);
if(regex.test(content)) {
emitter.emit('found', content);
}
})
})
return emitter;
}
findPattern(['a.js', 'b.js', 'main.js'], new RegExp("main", 'i'))
.on('error', function(err) {
console.log(err);
})
.on('fileRead', function(file) {
console.log(file + ' read\n');
})
.on('found', function(content) {
console.log(content.toString());
console.log('\n');
})
传播错误
EventEmitter
和回调函数一样,当异步事件发生错误的时候,直接抛出异常是无法被捕捉到的,因为它们所处的event loop
是不相同的
const EventEmitter = require('events').EventEmitter;
const fs = require('fs');
function findPattern(files, regex) {
const emitter = new EventEmitter();
files.forEach((file, index) => {
fs.readFile(file, (err, content) => {
if(err) {
// emitter.emit('error', err);
throw new Error(err);
}
emitter.emit('fileRead', file);
if(regex.test(content)) {
emitter.emit('found', content);
}
})
})
return emitter;
}
findPattern(['a.js', 'b.js', 'main.js'], new RegExp("main", 'i'))
.on('error', function(err) {
console.log(err);
})
.on('fileRead', function(file) {
console.log(file + ' read\n');
})
.on('found', function(content) {
console.log(content.toString());
console.log('\n');
})
所以我们平时在写代码的时候,要注意,多增加一个关于error
的事件进行监听,然后进一步处理
使任何对象可观察
有些时候,我们直接通过EventEmitter
去创建一个可观察对象是不够的,因为它不能够为我们提供扩展的功能,所以更多的时候,我们通过继承EventEmitter
这个类,去创建一个更具有扩展性的可观察的对象
为了进一步描述这种方法,我们通过重写上面的findPattern
来说明
const fs = require('fs');
const EventEmitter = require('events').EventEmitter;
class FindPattern extends EventEmitter {
constructor(regex) {
super();
this.regex = regex;
this.files = [];
}
addFile(file) {
this.files.push(file);
return this;
}
find() {
this.files.forEach((file, index) => {
fs.readFile(file, (err, content) => {
if(err) {
this.emit('error', err);
}
this.emit('fileRead', file);
if(this.regex.test(content)) {
this.emit('found', content);
}
})
})
}
}
const interface = new FindPattern(new RegExp("main"));
interface.addFile('a.js')
.addFile('b.js')
.addFile('main.js')
.on('error', function(err) {
console.log(err);
})
.on('fileRead', function(file) {
console.log(file + ' read\n');
})
.on('found', function(content) {
console.log(content.toString());
console.log('\n');
})
.find()
这种模式在Node的生态圈里十分常见,HTTP、TCP等模块里都大量了使用了这种模式
同步和异步事件
和回调函数一样,事件是可以同步触发,也可以是异步触发的,但是强调的是,在同一个EventEmitter
内,不能混用两种模式
emit同步事件和异步事件最主要的区别取决于注册listener的方法,如果events是异步的emit,那么程序有充足的时间去注册listener,因为event不会在本次event loop
被触发
如果events是同步的被emit,那么就需要在emit之前去注册listener
class SycnEmitter extends EventEmitter {
constructor() {
super();
this.emit('ready', 'ready');
}
}
const interface = new SycnEmitter();
interface.on('ready', (ready) => {
console.log(ready);
})
上面的代码,就是因为没有在emit之前进行注册,导致没有任何的输出结果,如果是异步的去emit的话,就不会这样。
所以我们在使用EventEmitter
的时候,需要考虑好使用的场景,再根据场景决定使用同步的方式还是异步的方式
EventEmitter VS callbacks
在定义异步API
时,常见的难点是检查是否使用EventEmitter
的事件机制或仅接受回调函数。一般区分规则是这样的:当一个结果必须以异步方式返回时,应该使用回调函数,当需要结果不确定其方式时,应该使用事件机制来响应。
但是,由于这两者实在太相近,并且可能两种方式都能实现相同的应用场景,所以产生了许多混乱。以下列代码为例:
function helloEvents() {
const eventEmitter = new EventEmitter();
setTimeout(() => eventEmitter.emit('hello', 'hello world'), 100);
return eventEmitter;
}
function helloCallback(callback) {
setTimeout(() => callback('hello world'), 100);
}
helloEvents()
和helloCallback()
在其功能上可以被认为是等价的,第一个使用事件机制实现,第二个则使用回调来通知调用者,而将事件作为参数传递。但是真正区分它们的是可执行性,语义和要实现或使用的代码量。虽然我们不能给出一套确定性的规则来选择一种风格,但我们当然可以提供一些提示来帮助你做出决定。
相比于第一个例子,即观察者模式而言,回调函数在支持不同类型的事件时有一些限制。但是事实上,我们仍然可以通过将事件类型作为回调的参数传递,或者通过接受多个回调来区分多个事件。然而,这样做的话不能被认为是一个优雅的API
。在这种情况下,EventEmitter
可以提供更好的接口和更精简的代码。
EventEmitter
更优秀的另一种应用场景是多次触发同一事件或不触发事件的情况。事实上,无论操作是否成功,一个回调预计都只会被调用一次。但有一种特殊情况是,我们可能不知道事件在哪个时间点触发,在这种情况下,EventEmitter
是首选。
最后,使用回调的API
仅通知特定的回调,但是使用EventEmitter
函数可以让多个监听器都接收到通知。
在定义异步API
时,常见的难点是检查是否使用EventEmitter
的事件机制或仅接受回调函数。一般区分规则是这样的:当一个结果必须以异步方式返回时,应该使用回调函数,当需要结果不确定其方式时,应该使用事件机制来响应。
但是,由于这两者实在太相近,并且可能两种方式都能实现相同的应用场景,所以产生了许多混乱。以下列代码为例:
function helloEvents() {
const eventEmitter = new EventEmitter();
setTimeout(() => eventEmitter.emit('hello', 'hello world'), 100);
return eventEmitter;
}
function helloCallback(callback) {
setTimeout(() => callback('hello world'), 100);
}
helloEvents()
和helloCallback()
在其功能上可以被认为是等价的,第一个使用事件机制实现,第二个则使用回调来通知调用者,而将事件作为参数传递。但是真正区分它们的是可执行性,语义和要实现或使用的代码量。虽然我们不能给出一套确定性的规则来选择一种风格,但我们当然可以提供一些提示来帮助你做出决定。
相比于第一个例子,即观察者模式而言,回调函数在支持不同类型的事件时有一些限制。但是事实上,我们仍然可以通过将事件类型作为回调的参数传递,或者通过接受多个回调来区分多个事件。然而,这样做的话不能被认为是一个优雅的API
。在这种情况下,EventEmitter
可以提供更好的接口和更精简的代码。
EventEmitter
更优秀的另一种应用场景是多次触发同一事件或不触发事件的情况。事实上,无论操作是否成功,一个回调预计都只会被调用一次。但有一种特殊情况是,我们可能不知道事件在哪个时间点触发,在这种情况下,EventEmitter
是首选。
总结
最后,使用回调的API
仅通知特定的回调,但是使用EventEmitter
函数可以让多个监听器都接收到通知。