C＃構造函數

Question

有人可以建議我在編寫C#構造函數時采取什么方法嗎？

在其他語言中，如C++ ，一切都很好 - 通常不會使內部字段可見並為它們提供getter / setter。

這意味着，您可以為您的班級提供構造函數，這些構造函數初始化您的所有/部分本地成員並感到高興。

---

但是， C#具有properties ，允許我們編寫如下內容：

Class x = new Class { Field1 = new Field1 ...., Field2 = new Field2 }

這允許鏈接對象構造，並且，正如我所假設的，可以刪除許多構造函數，如果我們沒有properties ，這將是必需的。

將此與屬性的默認值相結合，正如我所假設的，我們可以完全擺脫非專業的構造函數，它們實際上可以完成一些工作。

現在 - 是否可以刪除冗余構造函數並允許通過字段初始化構建對象？

這種方法的缺點是什么？ 有人可能會給出關於結合字段和構造函數的使用的一般建議 ，一些rules of thumb嗎？

謝謝。

Answer 1

我自己的經驗法則很簡單：如果需要某些東西來完全構造對象，它應該是一個ctor參數。

一個很好的例子是Stream輔助對象之一，如StreamReader或BinaryReader。 如果沒有關聯的Stream對象，它們就無法運行，因此必須在構造函數中指定它們。

Answer 2

在我看來，擁有你稱之為冗余構造函數的東西並沒有錯。 如果你想要定義一個構造函數就足夠了，那可能是因為真正需要這樣做。

Answer 3

構造函數可用於強制使用者為類提供值。

我的經驗法則是Fields用於可選數據，而構造函數可用於強制所需數據。

然而，這個問題是一種錯誤的二分法。 C ++的行為與C＃相同 - “Fields”（實際上是屬性 - 字段是類級變量）通常用作設置內部值的getter / setter，允許設置字段的new語法只是一種簡寫對於

Class x = new Class();
x.Field1 = new Field1();
x.Field2 = new Field2();

Answer 4

最佳做法是創建一個處於可用狀態的對象; 試圖限制對財產制定者的依賴。

它減少了創建不完整的對象並導致代碼不太脆弱的可能性。

Answer 5

您發布的代碼使用的是所謂的對象初始化器，它們實際上只是最近引入的語法糖。 使用對象初始化器只是調用構造函數和設置屬性的簡便方法。 您應該繼續在C＃中使用構造函數，就像在其他語言中使用它們一樣 - 一般規則是，如果一個類需要一個對象或值來正確初始化它，那么該參數應該通過構造函數傳遞。 如果不需要該值，則將其設置為可設置屬性是合理的。

一般來說，我避免使用制定者可能時（有很多，很多情況下，這是不可能的）， 在所有 。

Answer 6

在XAML中使用公共無參數構造以及屬性初始化的方法很受歡迎（需要？），很多WPF玩具都這樣做。

您面臨的唯一問題是部分初始化的對象，但是您可以在嘗試使用字段之前簡單地驗證對象狀態。

就個人而言，我在構造函數中創建了關鍵值參數，我從對象的副本和一系列可選參數中創建了復制構造函數，而我還沒有做出需要XAML消耗的東西。

Answer 7

對象初始化器語法只是一個語法糖。 即使在C＃1中你也可以寫

Class c = new Class();
c.Property1 = value1;
c.Property2 = value2;
c.Property3 = value3;
....

C＃3基本上將語法縮短為：

Class c = new Class 
{
   Property1 = value1, 
   Property2 = value2, 
   Property3 = value3
   ....
}

counstructor不僅僅是設置字段，構造函數應該根據參數邏輯構造對象，這樣當構造函數返回時，你得到的是一個可以使用的對象。

Answer 8

可以嗎？ 嗯，這取決於......

為了使用對象初始化器，您需要將公共setter暴露給您的所有字段，您可能不需要這樣。 如果你很樂意揭露它們，那么我會說繼續並刪除構造函數。 然而，僅僅因為你可以做某事並不意味着你應該 。 我會說如果你發現你的所有字段都是可公開設置的，那么刪除構造函數應該是你做的事情，不要讓字段可設置只是為了讓你刪除構造函數。

Answer 9

我懷疑你在這里指的是域對象，但是在服務的情況下，通過構造函數注入服務的依賴項使得服務更加自我記錄，而不是“新建”你的依賴項。 此外，這使您可以更輕松地使用依賴注入容器。