Flux Stores：为什么要扩展 EventEmitter.prototype？

Question

我能找到的每个官方 Flux 示例都使用这种模式来创建商店：

var MyStore = assign({}, EventEmitter.prototype, {
  ...
});

我不明白为什么我们直接在 MyStore 对象上分配方法，而我们可以通过使 MyStore 成为 EventEmitter 的实例来继承这些方法：

var MyStore = assign(new EventEmitter(), {
  ...
});

有人知道这种模式背后的基本原理吗？特别是因为它经常被误读，导致这样的错误：

var MyStore = assign(EventEmitter.prototype, {
  ...
});

如果我冒险猜测，我会说这是因为他们不想调用 EventEmitter 构造函数，他们希望您轻松地链接更多原型，如下所示：

var MyStore = assign({}, EventEmitter.prototype, A.prototype,
                     B.prototype, C.prototype, randomObject, {
  ...
});

Answer 1

一般来说，Javascript 中倾向于组合而不是继承。我想你可能会发现人们会争论继承的情况，但是，抛开任何在概念上优越的论点，JS 中的继承提供的一个特定优势组合是它可以让一个简单地模拟多重继承（否则不是可能在 JS 中）。

在 Object.assign() 进入 ES6 之前，像 jQuery、underscore/lodash 和原型这样的库有类似的函数，名为 extend()（至少现在 lodash 是它的 assign 函数的别名）。在我看来，extend 名称更容易了解它的使用方式/原因，但它只是一个名称。我认为一些库也有名为“mixin”的函数——同样的处理，组合的使用有时被称为使用“mixin”。

这个 SO 问题（及其最佳答案）可能很有趣Composition, Inheritance, and Aggregation in JavaScript

像许多 Javascript 习语一样，可能需要一些时间来适应，尤其是如果您有经典的 OO 背景。但是接受这个成语，你会习惯于更容易地发现你在问题末尾提到的那种错误，就像一个人习惯于处理闭包、异步代码和所有其他使 Javascript 变得狂野的事情一样很棒。