javascript - 原型(prototype)污染与专用库对象的性能和内存

Question

不确定这是否是一个新问题，所以如果您有任何好的来源，请引用。

我的团队正在开发一个大型 JS 图表项目，我们从以前的开发人员那里继承了这些项目，他们大量使用内置对象原型(prototype)来添加可重用代码。我们向 Date、Object 和其他内部对象添加了很多新的实用函数，所以我猜他们这样做是因为改变原型(prototype)提供了更直观的 API。

另一方面，我们的组件存在性能/内存问题，我们应用了所有可能的优化和最佳实践。我找不到关于 API 设计的。我正在尝试弄清楚是否更好地将内置对象的原型(prototype)与库代码结合起来，而不是通过某种命名空间模式将它们组合到专用对象中。

问题是哪种设计更好？它们中的一个是否会比另一个获得性能和/或内存？

Date.prototype.my_custom_function = new function (...) {...};
var period = new Date();
period.my_custom_function();

对比

DateLib.my_custom_function // defined in a DateLib function
var period = new Date();
DateLib.my_custom_function(period);

谢谢，伙计们，我们将不胜感激!

编辑:主要问题是我们的组件最终成为一个笨拙的 JS 野兽，它会降低某些移动设备的速度，尤其是旧设备，例如 iPad1 和早期的 Android ......我们已经做了很多优化，但我仍然看到几个有问题的部分。我想确定内置原型(prototype)污染是否是另一个需要研究的候选者。特别是 Date 和 Object 这两个家伙加载了大量典型的库代码。例如，事实上 my_custom_function 是一个很大的函数，它不是代码启动时位于 Date 原型(prototype)上的唯一附加成员。Object 加载得更多。大多数客户端代码没有使用这些附加功能，而是有意使用的 - 因此我们将决定我们最好坚持使用哪种方式:

• 继续使用原型(prototype)污染设计
• 将可重用的 API 重构为单独的库静态对象

老实说，我还没有运行性能基准测试，一旦有空就会运行。如果有人有结果/想法将会非常有帮助。

Answer 1

Modifying objects you don't own绝对是个坏主意。这里的选择是架构性的:如果您必须持久存储日期，则使用构造函数的私有(private)属性:

function DateLib() {
  this._dateObject = new Date();
}

DateLib.prototype.getDateString = function () {
  return this._dateObject.toDateString()
};

var dateLib = new DateLib();
dateLib.getDateString();

如果您只想对日期进行一些操作，请创建一个方法:

var DateLib = {
  toDateString: function (date) {
    return date.toDateString()
  }
}

DateLib.toDateString(new Date());

就性能而言，所有方法都是 are equally fast (感谢 Bergi，Esailija 的 alternative test)。

注意:这不是浏览器比较测试。测试是在不同的机器上进行的，因此这里只应分析方法与方法的性能。