Question

目前我正在编写一个小应用程序并且已经到了这一点，在那里我认为克隆一个对象更聪明，而不是使用引用。

我这样做的原因是，因为我正在收集列表中的对象。稍后我将只使用此列表，因为它是模型的一部分。引用不是我需要的东西，我想避免引用列表中的外部对象，因为我不希望有人构建构造，其中模型可以从代码中的不重要位置进行更改。（模型中信息的完整性非常重要。）

另外，当我不使用引用时，我认为我会从中获得更好的性能。

所以我的整体问题仍然是：我应该何时更喜欢克隆而不是javascript中的引用？

谢谢！

Answer 1

如果稳定性很重要，那么克隆它。如果测试显示这是一个瓶颈，请考虑将其更改为参考。如果它是一个瓶颈，我会感到非常惊讶，除非你有一个非常复杂的物体，它经常来回传递（如果你这样做，它可能表明设计不好）。

还要记住，你只能做很多事情来拯救其他开发者免于愚蠢。如果他们真的想破坏你的API，他们可以通过复制源代码或在运行时修改它来替换你自己的函数。如果您记录不得更改对象，那么优秀的开发人员（是的，有一些）将遵循该规则。

为了它的价值，我在自己的项目中使用了这两种方法。对于没有多次传递的小结构，我已经制作了稳定版本，对于较大的数据（例如可以在每帧传递的3D顶点数据），我不复制。

Answer 2

为什么不让列表中存储的对象不可变？

可以存储闭包，而不是存储类似JSON的简单对象

假设您有一个包含两个属性A和B的对象。它看起来像是：

myObj = {
   "A" : "someValue",
   "B" : "someOtherValue"
}

但是，正如你所说，任何人都可以通过简单地覆盖它的属性A或B来改变这个对象的状态。您可以传递从实际对象创建的只读数据，而不是将列表中的此类对象传递给客户端。

首先定义一个接受普通对象并向其返回一组访问器的函数：

var readOnlyObj = function(builder) {
    return {
        getA : function() { return builder.A; },
        getB : function() { return builder.B; } 
    }
}

然后，用户myObj代替您的对象readOnlyObj(myObj)，以便他们可以通过方法getA和getB访问属性。

这样可以避免克隆成本，并提供用户可以对对象执行的一组明确的有效操作。

什么时候我应该更喜欢克隆而不是javascript中的引用？

2 个答案: