構造函數的參數太多

我們有一個Transaction類，它非常容易加載;所以加載，我原本最終通過了近20個參數ctor。提取幾個值對象後，仍然有12個參數，我仍然認爲它太多了。構造函數的參數太多

我該如何去避免這種情況？我認爲將參數傳遞給構造函數是合理的，因爲它們都是必需的，我想明確說明。我也喜歡如果我添加一個屬性，我可以將其添加到ctor，讓我的編譯器找到它打破的位置，而不必依賴測試本身。我不認爲對象初始化器或者構建器能夠解決這個問題。在未來的日子裏，這些爭論可能會變得更加明顯，哪些爭論是共同的，儘管如此。

public class MyEntity() 
{ 
    public MyEntity(ValueType prop2, ValueType prop3, ...) 
    { 
     Id = Guid.NewGuid(); 
     Prop2 = prop2; 
     Prop3 = prop3; 
     ... 
    } 

    public Guid Id { get; private set; } 

    public ValueType Prop2 { get; private set; } 

    public ValueType Prop3 { get; private set; } 

    public ... 
}

來源

2013-01-15 JefClaes

這些參數可以用任何有意義的方式分組嗎？如果不是，他們服務的目的是什麼？ – Oded

如果這些參數具有所有相同的類型，只需使用MyEntity（params Type []參數），然後以不同的方式組織它們，如通過List或Dictionary ...或者傳遞結構或類作爲參數包含你需要的一切。另一種選擇是使用構造函數冒泡。 –

@Zarathos - 這違背了DDD，域的含義就是它的全部內容。 – Oded

您確定所有的參數都是必需的嗎？「required」這個詞具有欺騙性，例如，編譯器可能會強制我提供一個字符串參數，但它不會強制我提供一個不爲空或空的值。

真正強制提供有效數據的唯一方法是在使用時驗證它。有時這必須在構造函數中，例如一個包裝類僅在初始化時纔有意義的類，如I/O對象。但是，允許調用代碼以任何舊方式設置屬性通常就足夠了，然後在需要它們的方法調用中驗證它們的值。

我在散步。我的觀點是，不要掛上構造函數參數作爲向類提供初始化數據的唯一方法。除了簡單的屬性之外，它們提供的附加編譯器保護很少

來源

2013-01-15 20:09:45

這是一個銀行業務領域，所以如果你明白我的意思，我寧願永遠不要讓一個對象處於無效狀態。 – JefClaes

我也編寫銀行應用程序。我認爲沒有什麼能夠傳遞愚蠢的DTO，因爲這些數據在使用時被驗證。您選擇的架構模式應該指導您的類設計，而不是您的驗證策略的低級細節。 –

如何將參數封裝在結構中，並將結構傳入？

public struct ParamsStruct 
{ 
    Type1 param1; 
    Type2 param2; 
    ... 
} 

public void Method(ParamsStruct p) 
{ 
    ... 
} 

public void Main(String[] args) 
{ 
    ParamsStruct p; 
    p.param1 = ... 
    p.param2 = ... 
    Method(p); 
}

來源

2013-01-15 20:12:50 Porkbutts

這不就是解決問題嗎？ – JefClaes

至少你可以將這些參數邏輯分組到幾個結構中，這應該有助於組織。 – Porkbutts

我同意最後的評論。我將嘗試發現更多的概念。 – JefClaes

public class MyEntity() 
{ 
    public ValueType Prop1 { get; set; } 

    public ValueType Prop2 { get; set; } 

    // And so on... 

    public MyEntity() 
    { 
     Id = Guid.NewGuid(); 
    } 
}

然後：

MyEntity entity = new MyEntity(); 
entity.Prop1 = prop1; 
entity.Prop2 = prop2; 
// And so on...

最後，您可以考慮兩種不同的設計方法：

的 essence 模式。
fluent interface 模式。

來源

2013-01-15 20:35:38

當您在用戶或系統界面中輸出完整的交易詳情時，您將需要所有的零件。這不太可能幫助您找到拆分。

但是，看看您的內部處理 - 是否存在您僅使用交易中字段子集的情況？你有沒有在交易中通過的地方，但只使用4個字段？如果您從字面上始終使用所有字段，請將它們保存在一個對象中。

在銀行交易的情況下，我會考慮拆分沿着這些線路： -

這些錢從
的錢哪裏去了
的錢是如何移動來了 - 該支付工具或設備使用
爲什麼錢很感動 - 參考號碼等
的金額和幣種
日期
交易

的狀態（顯然，這取決於你的精確域）。

來源

2013-01-16 00:49:43

構造函數的參數太多

回答

相關問題