创build一个自己的对象来使事件在代码完成中有什么优点/缺点？

在nodejs应用程序中，我们有许多事件将被发射和捕获。 事件通常被定义为简单的string，比如“open”。 我的想法是为我的事件创build一个自己的对象。

var event = { open: 'my-open', close: 'my-close' }; module.exports = event; 

想要的好处是：

• 定义所有事件被定义的位置
• IDE内的代码完成（例如IntelliJ）

我的问题是，如果这是一个好主意，或者如果有严重的理由不这样做？

更新
我们决定只在一个模块中使用这样的事件对象。
好处是：

• 定义事件的地点
• 组织事件的可能性
• 将这些事件重命名为一个地方
• IDE支持（代码完成，查找参考）

Answer 1

我在这方面有点两面性：

• 一方面，我可以看到明显的好处，例如使用自动完成的IDE时。 此外，你有一个单一的地方你的事件定义的优势。 另外，这意味着当你发出一个事件的时候，你可以通过查看代码来明确地区分你的自定义事件和Node.js自己的事件。 他们是不同types的事件，他们只是看起来不同。

• 另一方面，我认为这太复杂了。 本质上，Node.js中的事件只是一个string。 而你的build议依赖于对象属性的名字，最后也是string。 没有编译器支持，因为没有编译器。 因此，如果您输错了实际的事件名称，或者输错事件包装属性的名称，则无关紧要。

换句话说：如果你不使用IDE，那完全没有帮助。 相反，它会迫使你在一个地方收集所有可能的事件名称，这将使维护事件变得困难。 想想很长一段时间的大量事件：哪些事件可以安全地移除，而不会在完全不同的地方破坏代码，甚至可能在不同的模块中？ 或者，由于事件名称甚至可能在其他模块中使用，您必须search所有模块。 在这种情况下，我可以 – 只需要search一个string。

如果我比较好处和风险，我可能会使用事件名称作为简单的string，就像Node.js本身一样。

最后，还有一件事要注意：有时候需要通过在运行时build立事件名称string来dynamic创build事件名称。 只要你有这样的事情，你最终会有两种不同的风格发出你的自定义事件，这打破了你有一个一致的事件风格的规则…所以，如果我认为这一点，我会更谨慎。

而且，（现在真的）终于，最后一件事了：引入这样的对象并不能改善你的代码。 它提高了与IDE的兼容性。 我怀疑这是否是一种解决scheme，我宁愿将其视为一种解决方法。