[Parameters] 有多少構造函數參數太多?


Answers

我看到有些人推薦七個作為上限。 顯然,人們一下子就能把七件事情掌握在腦海裡, 他們只能記得四(蘇珊Weinschenk, 每個設計師需要了解的人100件事 ,48)。 即便如此,我認為四是一個高地球軌道的東西。 但那是因為我的想法被鮑勃·馬丁改變了。

清潔代碼中 ,Bob叔叔認為三個參數的數量是一般的上限。 他提出了激進的要求(40):

一個函數的理想參數個數是零(niladic)。 接下來是一個(monadic)緊跟著兩個(二元)。 應盡可能避免三個論點(三元)。 超過三個(多邊形)需要非常特殊的理由 - 然後不應該使用。

他說這是因為可讀性; 而且還因為可測性:

想像一下編寫所有測試用例的困難,以確保所有不同的參數組合都能正常工作。

我鼓勵你找到他的書的副本,並閱讀他對功能論點的充分討論(40-43)。

我同意那些提到單一責任原則的人。 我很難相信,一個需要超過兩三個價值/對象,而沒有合理的違約的類實際上只有一個責任,而且不會因另一個類被提取而更好。

現在,如果你通過構造函數注入你的依賴關係,那麼Bob Martin關於調用構造函數是多麼容易的論點並不太適用(因為通常在你的應用程序中只有一個點將你連接起來,或者你甚至有一個框架,為你做)。 然而,單一責任原則仍然是相關的:一旦一個班級有四個依賴關係,我認為這是一個正在做大量工作的氣味。

然而,和計算機科學中的所有東西一樣,有大量的構造函數參數是有效的。 不要扭曲你的代碼,以避免使用大量的參數; 但是如果你使用了大量的參數,請停下來思考一下,因為這可能意味著你的代碼已經被扭曲了。

Question

假設您有一個名為Customer的類,其中包含以下字段:

  • 用戶名
  • 電子郵件
  • 名字

我們還要說,根據您的業務邏輯,所有Customer對像都必須定義這四個屬性。

現在,我們可以通過強制構造函數指定每個屬性來輕鬆完成此操作。 但是當你被迫向Customer對象添加更多必需的字段時,很容易看出這會如何失控。

我已經看到有20多個參數被引入構造函數的類,使用它們只是一個痛苦。 但是,或者,如果您不需要這些字段,那麼如果您依賴調用代碼來指定這些屬性,就會面臨未定義信息的風險,或者更糟糕的是,會導致對象引用錯誤。

有沒有其他的選擇,或者你只是要決定X的構造函數參數太多,你可以住?




如果你有很多參數,那麼把它們一起打包到結構體/ POD類中,最好聲明為正在構建的類的內部類。 這樣,您仍然可以在使調用構造方法的代碼合理可讀時仍然需要這些字段。




風格很重要,在我看來,如果有一個有20多個參數的構造函數,那麼設計就應該改變。 提供合理的默認值。




我想這一切都取決於情況。 對於你的例子,一個客戶類,我不會冒這個數據在需要的時候被定義的機會。 另一方面,傳遞一個結構會清除參數列表,但是在結構中仍然需要定義很多東西。




我同意對Boojiboy提到的7個項目的限制。 除此之外,可能值得查看匿名(或專用)類型,IDictionary或間接通過主鍵到另一個數據源。




除非超過1個參數,否則我總是使用數組或對像作為構造函數參數,並依靠錯誤檢查來確保所需的參數在那裡。




我認為你的問題更多地是關於你的類的設計,而不是關於構造函數中的參數的數量。 如果我需要20個數據(參數)來成功地初始化一個對象,我可能會考慮分解這個類。