值物件

在編寫程式時，我常發現將事物表示為複合體很有用。2D 座標包含 x 值和 y 值。金額包含數字和貨幣。日期範圍包含開始和結束日期，而這些日期本身可以是年、月和日的複合體。

在這樣做的過程中，我遇到了兩個複合物件是否相同的疑問。如果我有兩個點物件，都表示笛卡兒座標 (2,3)，將它們視為相等是有道理的。由於其屬性的值（在本例中為其 x 和 y 座標）而相等的物件稱為值物件。

但是，除非我在編寫程式時小心，否則可能無法在程式中獲得這種行為

假設我想在 JavaScript 中表示一個點。

const p1 = {x: 2, y: 3};
const p2 = {x: 2, y: 3};
assert(p1 !== p2);  // NOT what I want

很遺憾，該測試通過了。它之所以通過，是因為 JavaScript 透過查看 js 物件的參考來測試相等性，而忽略了它們所包含的值。

在許多情況下，使用參考而不是值是有道理的。如果我要載入和處理一堆銷售訂單，將每個訂單載入單一位置是有道理的。如果我接著需要查看 Alice 的最新訂單是否在下一批交貨中，我可以取得 Alice 訂單的記憶體參考或身分，並查看該參考是否在交貨中的訂單清單中。對於此測試，我不必擔心訂單中包含什麼。同樣地，我可能會依賴唯一的訂單編號，測試以查看 Alice 的訂單編號是否在交貨清單中。

因此，我發現將物件分成兩類很有用：值物件和參考物件，這取決於我如何區分它們[1]。我需要確保我了解我期望每個物件如何處理相等性，並對它們進行編寫程式，以便它們根據我的期望來表現。我如何做到這一點取決於我正在使用的程式語言。

有些語言將所有複合資料視為值。如果我在 Clojure 中建立一個簡單的複合，它看起來像這樣。

> (= {:x 2, :y 3} {:x 2, :y 3})
true

這是函數式風格 - 將所有內容視為不可變值。

但如果我不使用函數式語言，我仍然常常可以建立值物件。例如在 Java 中，預設的點類別會按照我想要的方式運作。

assertEquals(new Point(2, 3), new Point(2, 3)); // Java

運作方式是點類別使用值測試覆寫預設的 equals 方法。[2] [3]

我可以在 JavaScript 中執行類似的事情。

class Point {
  constructor(x, y) {
    this.x = x;
    this.y = y;
  }
  equals (other) {
    return this.x === other.x && this.y === other.y;
  }
}

const p1 = new Point(2,3);
const p2 = new Point(2,3);
assert(p1.equals(p2));

這裡 JavaScript 的問題是，我定義的這個 equals 方法對其他任何 JavaScript 函式庫來說都是個謎。

const somePoints = [new Point(2,3)];
const p = new Point(2,3);
assert.isFalse(somePoints.includes(p)); // not what I want

//so I have to do this
assert(somePoints.some(i => i.equals(p)));

這在 Java 中不是問題，因為 Object.equals 是在核心函式庫中定義的，而所有其他函式庫都使用它進行比較（== 通常只用於基本型別）。

值物件的一個好處是，我不需要在意我是在記憶體中擁有對相同物件的參考，還是擁有具有相同值的另一個參考。然而，如果我不小心，這種快樂的無知可能會導致問題，我會用一點 Java 來說明。

Date retirementDate = new Date(Date.parse("Tue 1 Nov 2016"));

// this means we need a retirement party
Date partyDate = retirementDate;

// but that date is a Tuesday, let's party on the weekend
partyDate.setDate(5);

assertEquals(new Date(Date.parse("Sat 5 Nov 2016")), retirementDate);
// oops, now I have to work three more days :-(

這是 別名錯誤 的範例，我在一個地方變更日期，而它產生的後果超乎我的預期 [4]。為了避免別名錯誤，我遵循一個簡單但重要的規則：值物件應該是不可變的。如果我想變更我的派對日期，我會建立一個新的物件。

Date retirementDate = new Date(Date.parse("Tue 1 Nov 2016"));
Date partyDate = retirementDate;

// treat date as immutable
partyDate = new Date(Date.parse("Sat 5 Nov 2016"));

// and I still retire on Tuesday
assertEquals(new Date(Date.parse("Tue 1 Nov 2016")), retirementDate);

當然，如果值物件真的是不可變的，那會讓它們更容易被視為不可變的。對於物件，我通常可以透過不提供任何設定方法來做到這一點。因此我早先的 JavaScript 類別看起來像這樣： [5]

class Point {
  constructor(x, y) {
    this._data = {x: x, y: y};
  }
  get x() {return this._data.x;}
  get y() {return this._data.y;}
  equals (other) {
    return this.x === other.x && this.y === other.y;
  }
}

雖然不可變是我避免別名錯誤最喜歡的方法，但也可以透過確保指定作業總是會建立一個副本來避免它們。有些語言提供這種功能，例如 C# 中的結構。

是否將概念視為參考物件或值物件取決於你的情境。在許多情況下，將郵遞地址視為具有值相等的簡單文字結構是值得的。但更精密的對應系統可能會將郵遞地址連結到一個精密的階層模型中，其中參考更有意義。與大多數建模問題一樣，不同的情境會導致不同的解決方案。 [6]

通常建議將常見的原始資料，例如字串，替換為適當的值物件。雖然我可以將電話號碼表示為字串，但轉換成電話號碼物件可以讓變數和參數更明確（在語言支援時進行類型檢查），成為驗證的自然焦點，並避免不適用的行為（例如對整數 ID 號碼進行算術運算）。

點、金錢或範圍等小物件是值物件的良好範例。但較大的結構通常可以編寫成值物件，如果它們沒有任何概念上的識別碼或不需要在程式中分享參考。這更適合預設為不可變的函數語言。[7]

我發現值物件，特別是小物件，通常被忽略 - 被視為太微不足道而沒有思考的價值。但一旦我發現了一組好的值物件，我發現我可以為它們建立豐富的行為。若要體驗這一點，請嘗試使用 範圍類別，並了解它如何透過使用更豐富的行為來防止對開始和結束屬性進行各種重複的調整。我經常遇到程式碼庫，其中像這樣的特定於網域的值物件可以作為重構的焦點，從而大幅簡化系統。這種簡化通常會讓人感到驚訝，直到他們看過幾次 - 到那時它就是一位好朋友了。