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


Answers

我看到一些人推薦七個作為上限。 很明顯,人們可以一次把七件事情放在腦海中, 他們只能記得四個(蘇珊Weinschenk, 每個設計師需要知道的100件事情 ,48人)。 即便如此,我認為四者是高地球軌道。 但那是因為我的想法被鮑勃馬丁改變了。

Clean Code中 ,Bob叔叔認為三是參數數量的一般上限。 他提出了激進的主張(40):

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

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

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

我鼓勵你找到他的書的副本,並閱讀他對函數論點的全面討論(40-43)。

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

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

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

Question

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

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

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

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

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

有沒有其他的選擇呢,或者你是否需要決定是否有太多的構造函數參數可供您使用?




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




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




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




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




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




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