什么時候我應該更喜歡克隆而不是javascript中的引用？

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訪問屬性。

這樣，您可以避免克隆成本，並提供用戶可以對對象執行的一組明確的有效操作。