javascript - 在原型(prototype)上使用闭包有缺点吗？

Question

我喜欢使用闭包创建具有私有(private)属性的对象的一般风格。我不确定是在闭包内还是在对象的实际原型(prototype)上创建原型(prototype)方法是否更有效。考虑以下示例:

const A = function(a, b) {

  this.a = a;
  this.b = b;

};

A.prototype = {

  add:function() { this.a += this.b; }

};

const B = (function() {

  function add() { this.a += this.b; }

  return function(a, b) {

    return { a, b, add };

  };

})();

示例 A 是带有原型(prototype)的传统构造函数。使用它看起来像这样:

var a = new A(1, 1);
a.add(); // a.a == 2;

示例 B 是使用闭包的技术。使用它看起来像这样:

var b = B(1, 1);
b.add(); // b.a == 2;

我期望 a 工作的方式是 A 的每个实例都有 a 和 b 属性以及指向包含 add 方法的原型(prototype)对象的指针。
我期望 b 工作的方式是 B 的每个实例都有 a 和 b 属性以及指向 add 方法的指针。 B 函数有一个包含 add 方法的闭包。 add 方法只在定义 B 时定义一次。这似乎是在 JS 中创建“原型(prototype)”属性和方法的一种不错的方式。有谁知道这是创建具有“共享”属性的对象的高性能方法，还是使用原型(prototype)的传统方法的可行替代方案？

Answer 1

您的闭包示例对于那种风格的构建器函数来说有点不典型，因为它不会在 B 中创建任何函数。本身，就在创建 B 的匿名函数中;这意味着它避免了通常的次要缺点(每次调用 B 时重新创建函数)。 (通常“闭包风格”会在 B 本身中创建函数，因此它可以直接在执行上下文中使用 a 和 b，而不是使用 this.a 和 this.b 属性。)
我看不出你正在做的任何性能下降。从理论上讲，它会有非常轻微的性能提升(完全除了您观察到对象文字比使用 new 快得多)，因为实例上的方法是自己的属性而不是继承的属性等等(理论上) 它们查找起来会稍微快一些(因为 JavaScript 引擎会立即在对象上找到它们，而不是在对象本身上找不到它们而不得不去查看原型(prototype))。但实际上，我希望任何现代 JavaScript 引擎都能优化，这样您就不会从中受益。
我可以看到一些非性能方面的缺点，但没什么大不了的:

一切都只是一个对象，所以如果你正在调试一个不相关的性能问题并查看堆快照，一切都只是 Object而不是 A或 B或 C ，这使得使用内存分析器变得更加困难。我试图通过添加 constructor 来获取内存配置文件以对其进行分类。属性(property)，但它不起作用(无论如何在 Chrome 中)。我认为它使用了对象原型(prototype)的构造函数。您可以通过给对象一个特定于构造函数的原型(prototype)来解决它，只是不使用它，但这似乎有点奇怪。

要在不使用原型(prototype)对象的情况下增强对象，您必须改用 mixins，这意味着将所有属性从一个对象复制到另一个对象，这需要更多工作，并且意味着每个对象都比使用原型(prototype)继承时更大，可能会在低端设备(手机等)上造成内存流失。 (或者，使用组合而不是增强，这样做有不同的论据。)

你正在与语言对抗。 JavaScript 的原型(prototype)本质是其本质的重要组成部分(即使您不使用构造函数而是使用 Object.create 或类似函数)。 JavaScript 引擎旨在擅长优化原型(prototype)关系。你会做其他事情。它可能很好，只是看起来不太理想。

当使用的模式不典型时，其他人就很难跟上代码库的速度。使用 JavaScript 的三种典型方式是构造函数(带有原型(prototype))，非 this关闭/Object.create方式(使用原型(prototype))和函数式编程。你正在看的是前两者的混合。

但是，如果您正在解决与对象创建速度相关的特定问题，那么有针对性地使用这种稍微不寻常的模式可能会非常成功。或者您可能只是更喜欢它，并乐于接受不利的一面。 :-)