使函数表现得像实例化的 EventEmitter

Question

我非常喜欢将函数导出为 JavaScript 模块的主要 API 的模式。原因是在 JS 中，一个函数基本上可以做任何典型对象可以做的事情，然后再做一些。

所以这对我来说很典型：

function stuff() {}
function thing() { /* shortcut or default behavior */ }
thing.stuff = stuff;
module.exports = thing;

现在我遇到了一种情况，我希望thing 的行为类似于EventEmitter 的实例。而且我不希望它成为构造函数。

为什么？好吧，thing 确实与osPreferences 类似，使用一些选项调用它会将数据保存到磁盘。用户实例化它没有任何意义。 new OSPreferences() 没有多大用处，因为您的计算机一次只能尊重一组偏好。

然而，更改可以随时发生，在我的 API 之外。所以有一个巨大的好处：

osPreferences.on('change', fn);

所以问题是，什么是吸收 EventEmitter instance 行为的可靠模式？简单地遍历一次性实例的所有属性并将它们复制到目标函数是否足够好？是否值得尝试模仿继承与非继承的设置？考虑到默认的this 将被更改，是否有任何奇怪的情况需要考虑？或者有没有更好、更明智的方法？

Answer 1

简单地遍历一次性实例的所有属性并将它们复制到目标函数是否足够好？

是的。您甚至不需要创建一次性实例，您只需将所有 EventEmitter.prototype 方法复制到您的函数中，然后将 EventEmitter 应用到它。

function osPreferences() { … }
for (var p in EventEmitter.prototype)
    osPreferences[p] = EventEmitter.prototype[p];
EventEmitter.call(osPreferences);

是否值得尝试模仿继承与非继承的设置？

不是真的。你坚持单例使用你的 api，所以你根本不需要任何继承。

考虑到默认的this 将被更改，是否有任何奇怪的情况需要考虑？

不，EventEmitter is coded quite defensively。当然，您的听众可能会觉得这很不寻常……

Answer 2

循环和复制原始对象的方法和属性可能会失败，具体取决于 EventEmitter 的实现方式。当大量使用闭包来隐藏属性时，这种方法最有可能失败。

在我看来，最好的方法是直接在你的函数实例上设置原型。以您的示例为例，它将类似于：

var OSPreferences = function(){
  // ...
};

Object.setPrototypeOf(OSPreferences, new EventEmitter());

Answer 3

ES6 class syntax 是最优雅的子类化解决方案。

let EventEmitter = require('events'); //or `require('events').EventEmitter` in nodejs
Class osPreferences extends EventEmitter{
    constructor(){
        super();
        console.log(this);
    }
}
let osp = new osPreferences();
osp.on('change',function(){
    console.log('osPreferences changed');
});
osp.emit('change');

很遗憾，最新的 Node 版本不支持类语法。您必须改用iojs。