構造函數或屬性：在分配值時哪一個是更好的選擇

Question

當我們應該在賦值時使用構造函數而不是屬性，反之亦然。

Answer 1

構造函數是一種非常方便和強大的契約類型 - 一種要求消費者在甚至可以使用您的對象之前提供某些信息的方法。 因此，對於實例正常運行所必需的信息，請使用構造函數參數。 這是依賴注入的基本概念 - 您在完成工作時所依賴的任何東西，必須在開始之前注入（提供）給您。

屬性可以代表一個有趣的問題。 一般來說，經驗告訴我，只要有可能，屬性應該是只讀的，對象通常應該盡可能外部不變。 向屬性添加公共setter是您的類的復雜性的乘數。 當然，總有一些對象類型 - 實體就是一個很好的例子 - 其中setter是有意義的。 但是對於大多數對象來說，狀態的“通過構造函數寫入”/“通過屬性讀取”的模式大大降低了我負責的應用程序的復雜性和錯誤風險。

Answer 2

如果構造對象確實需要參數值，則使用構造函數（沒有它們，對象無法啟動）。 對具有可接受的默認值的參數使用屬性，因此可以根本不分配它們。 您可以提供一些額外的構造函數，這些構造函數會將一些屬性作為速記分配給您的用戶。

Answer 3

在一些情況下，可變性質可能更可取：

1. 對於“純”可變數據對象，僅設置屬性不會產生副作用。 例如，您可能有一個對象代表數據庫中的某個實體，但在您顯式執行Commit操作之前，修改其屬性不會產生任何影響。 該對象是用於包含數據的包，但沒有任何內容直接對數據中的更改做出反應。

2. 如果您有大量可配置狀態會影響某些操作，並且許多可配置屬性具有有意義的默認值。 如果這些是執行操作的類的屬性，則通常會有一些“凍結”狀態的概念，以便可變屬性在操作運行時拋出異常。

3. 如果您正在開發一個將由可視化設計器或依賴於反射屬性的其他系統使用的類。 例如，WPF中的數據綁定系統廣泛使用可變屬性作為​​傳遞UI交互的方式。 通過適當的設計來管理這些突變，您可以創建一些非常強大且響應迅速的接口。

Answer 4

當需要任意理智的初始值時，可以使用構造函數;如果希望稍后可以更改值，則使用屬性。