關於 Immutable Object 模式適用場景的探討

什麼是 Immutable Object

Immutable Object 模式是一種將對象設計爲一旦建立就不能修改其屬性值，全部的屬性值都只有 getter 方法沒有 setter 方法的模式。

該模式有兩種實現途徑：一是在構造方法中提供全部屬性的參數，設置好全部的屬性值；二是提供 builder 方法來讓用戶逐步設置屬性值，最後再建立對象實例。前者的好處是代碼量較少，後者的好處是方便用戶自由選擇給哪些屬性賦值。

Immutable Object 的優勢

一個不能修改屬性值的對象有什麼優勢呢？首先它是線程安全的，並且多個線程對它的訪問不須要有任何同步操做，所以不會對線程的運行效率產生任何影響。

其次是在某些場景下，使用 Immutable Object 這種保守的封裝方式能避免一些問題的發生。

舉個例子，HttpClient 經過配置對象來進行初始化，而這個配置對象是調用者給過來的，這意味着調用者可能會繼續持有該對象，甚至在 HttpClient 的運行過程當中還會試圖修改配置對象的屬性。

這麼作是存在比較嚴重的問題的。首先，這些修改有多是無效的，由於一旦完成初始化，配置對象中的一些屬性就不會再用到了；其次，有些修改可能會致使併發問題，由於配置對象是會被多線程訪問的；再次，只有初始化過程會對配置屬性進行檢查，若是一個屬性在這以後被修改爲了一個無效的值，這會致使故障的發生。

因此，將配置對象設計爲 Immutable Object，就能避免上面所說的問題，極大的提升應用的健壯性。

避免濫用 Immutable Object

但若是一個對象不存在上面所說的使用場景，那麼就不須要將其設計爲 Immutable Object。典型的例子就是 DTO 對象，這類對象的職責僅僅是傳遞數據，其生命週期很短，甚至在方法執行完後就立刻失去任何引用，能夠被回收了。

對 DTO 對象的屬性進行修改不會引起任何問題。由於做爲傳遞對象，發送方只會寫，接收方只會讀，並不須要作特別的限制。

更重要的是，DTO 對象是必定有序列化和反序列化的要求的，這是它的一個自然職責，Immutable Object 由於缺乏 setter 方法，會讓全部依賴 setter 方法進行反序列化的框架沒法正常運做。因此 Immutable Object 不適合用在 DTO 類上。

總之，咱們在對一個類應用特別的設計模式時，最好先考慮清楚這個設計模式的目的和適用場景，這個類是否符合這個場景。