本系列目錄：Abp介紹和經驗分享-目錄

這篇是之前翻備忘錄發現漏了的，前陣子剛好同事又提及過這個問題，這裡補上。
本文重點在於理解什麼是值物件的不可變性。

Abp的ValueObject以及EF的ComplexType

Abp中對應DDD概念的值物件有個基類：ValueObject<T>。
這個基類預設重寫了Equals，GetHashCode等用於比較兩個例項是否相等的方法和過載了==，!=操作符。
在構建一些比較複雜的實體時，我們可以把屬於同一個概念的多個屬性或欄位封裝成一個值物件。
這個值物件在實體中又對應EntityFramework的複雜型別ComplexType。
所以在記憶體中或者在資料庫中，這個物件都可以作為一個整體被賦值、複製或修改

如果不加控制，修改很有可能發生，但是，這類物件，必須設計成不可變的！不能被修改！

用兩個測試用例舉個反例

還是Personball.Demo解決方案。
這已經是我的御用示例專案了，我本地git庫保留master分支為當初下載的原始zip檔案解壓後的原始碼，新開一篇文章就建個新分支折騰。

我們假設一個場景：

我們有一個創業者A的住址資訊，他要開辦一家公司A，由於資源不足，他希望把自己的住址登記成公司的辦公地址。

我們在Personball.Demo.Core專案根目錄加兩個值物件Address1和Address2：

public class Address1 : ValueObject<Address1>
{
    public string RegionCode { get; set; }

    public string Street { get; set; }
}

public class Address2 : ValueObject<Address2>
{
    protected Address2()
    {
        //for orm
    }

    //只能通過ctor構造
    public Address2(string regionCode, string street)
    {
        RegionCode = regionCode;
        Street = street;
    }

    //setter 被保護起來了
    public string RegionCode { get; protected set; }
    //setter 被保護起來了
    public string Street { get; protected set; }
}
 

新建Creators目錄，加實體Creator:

public class Creator : Entity
{
    public Address1 HouseAddress1 { get; set; }

    public Address2 HouseAddress2 { get; set; }
}

新建Companies目錄，加實體Company:

public class Company : Entity
{
    public string Name { get; set; }

    public Address1 OfficeAddress1 { get; set; }

    public Address2 OfficeAddress2 { get; set; }
}
 

在Personball.Demo.Tests專案中新建目錄Companies加測試檔案Company_Tests。

如果測試資源管理器無法發現單元測試用例，可以刪掉臨時目錄%TEMP%\VisualStudioTestExplorerExtensions，再重啟VS即可。

第一個測試用例：

[Fact]
public void HouseAddress1_Should_Not_Be_Modified1()
{
    var creatorA = new Creator
    {
        HouseAddress1 = new Address1
        {
            RegionCode = "100100",
            Street = "xxxx路xxxx號101。"
        },
        HouseAddress2 = new Address2("100100", "xxxx路xxxx號101。")
    };

    var companyA = new Company
    {
        Name = "xxx初創公司",
        //公司地址用A的住址，合情合理
        OfficeAddress1 = creatorA.HouseAddress1,
        OfficeAddress2 = creatorA.HouseAddress2
    };

    //迭代N次後，可能會有這種需求（辦公地址後面追加個公司名稱）
    companyA.OfficeAddress1.Street += companyA.Name;

    //斷言失敗，creatorA.HouseAddress1.Street已被修改！
    //creatorA.HouseAddress1.Street.ShouldBe("xxxx路xxxx號101。");
    
    //是同一個例項！
    creatorA.HouseAddress1.ShouldBeSameAs(companyA.OfficeAddress1);
}

不要吐槽上面這個生造的需求，“辦公地址後面加個公司名稱”，只是表達這個意思：

我們很可能在維護了幾個月程式碼後，不經意間，會將一個實體的一個值物件賦值給另一個實體，另一個實體又緊接著修改了自己的這個值物件中的某個屬性。

也可能加了這行程式碼“辦公地址後面加個公司名稱”的已經是另一個人了。
這個問題如果發生了，很難定位排查。
那麼如何防止這種情況發生？

第二個測試用例：

[Fact]
public void HouseAddress2_Should_Not_Be_Modified2()
{
    var creatorA = new Creator
    {
        HouseAddress1 = new Address1
        {
            RegionCode = "100100",
            Street = "xxxx路xxxx號101。"
        },
        HouseAddress2 = new Address2("100100", "xxxx路xxxx號101。")
    };

    var companyA = new Company
    {
        Name = "xxx初創公司",
        OfficeAddress1 = creatorA.HouseAddress1,
        OfficeAddress2 = creatorA.HouseAddress2 //不經意就會這麼幹
    };

    //迭代N次後，不小心可能會這麼幹
    //編譯器報錯，setter無法訪問！
    //companyA.OfficeAddress2.Street += companyA.Name;
    
    //想改就必須new一個！
    companyA.OfficeAddress2 = 
        new Address2(companyA.OfficeAddress2.RegionCode, 
                    companyA.OfficeAddress2.Street + companyA.Name);
    
    //斷言通過，creatorA.HouseAddress2.Street不受影響！
    creatorA.HouseAddress2.Street.ShouldBe("xxxx路xxxx號101。");
    
    //不同例項！
    creatorA.HouseAddress2.ShouldNotBeSameAs(companyA.OfficeAddress2);
}

當我們用了Address2，其屬性的setter都被protected限制了從外部直接賦值時，companyA.OfficeAddress2.Street不能被直接修改了！
想修改它時，必須new一個新例項！這時候，對creatorA.HouseAddress2自然是沒有影響的。
這並不是特別高深的原理（很基礎的OOP知識點），但是能從根本上預防上述問題。

總結

值物件必須被設計成不可變的，當你（或者其他人）想修改它時，必須new一個新例項！

值物件必須被設計成不可變的，當你（或者其他人）想修改它時，必須new一個新例項！

值物件必須被設計成不可變的，當你（或者其他人）想修改它時，必須new一個新例項！

重要的事說三遍，剛才說了預防問題的原理很簡單，這個導致問題的原理其實也很簡單。
就是OOP程式語言，其主要型別都是引用型別，變數hold的大多時候都是一個地址。
很多時候都是地址傳來傳去，一個不注意，修改物件的影響範圍是在你預料之外的。
因此，OOP語言基本都有限制可訪問性的關鍵字（基於類的鐵定有，基於原型的沒仔細研究過，不確定）

話說回來，如果有幾年工作經驗了，卻發現好多語言層面的關鍵字被冷落，是不是該反思下。。。

如果說從貧血模型到充血模型是一次成長，從充血模型到重新審視語言層面提供的特性，又是一次成長。

最後囉嗦一句，其實實體的各種屬性更應該被保護起來，限制必須通過方法去修改。
否則，你如何保證以後維護程式碼的三個月後的自己或者其他人會遵守之前的業務規則？

如果是主從關係的多個實體，那就通過聚合根去約束，更復雜的，通過領域服務去約束。

Over.