如果您使用Inversion of Control，構造函數的大小是否很重要？

Question

所以我可能有10個對象，每個對象都有1-3個依賴關係（就鬆散耦合而言，我認爲沒問題），但也有一些設置可以用來定義行爲（超時，窗口大小等） ）。

現在在我開始使用Inversion of Control容器之前，我會創建一個工廠，甚至可能爲每個對象創建一個簡單的ObjectSettings對象，這需要超過1個設置才能將構造函數的大小保持爲建議的「less比4「參數大小。我現在正在使用控制容器的倒置，我只是沒有看到它的所有重點。當然，我可能會得到一個有7個參數的構造函數，但是誰在乎？無論如何，這些都由IoC填寫。

我在這裏錯過了什麼，或者這基本上是正確的？

Answer 1

在閱讀這個問題之前，我沒有發現類複雜性和IoC構造函數的大小之間的關係，但是我的分析表明，在IoC構造函數中有很多參數是code smell在使用IoC時需要注意。有一個目標堅持一個簡短的構造函數參數列表將幫助你保持這些類本身的簡單性。在single responsibility principle之後會引導你走向這個目標。

我工作的系統目前有122個使用Spring.NET框架實例化的類。這些類之間的所有關係都在其構造函數中設置。無可否認，該系統在我違反了一些規則的情況下，其公平份額不夠完美。 （但是，嘿，我們的失敗是學習的機會！）

這些類的構造函數具有不同數量的參數，我在下表中顯示。

Number of constructor arguments Number of classes 
      0        57 
      1        19 
      2        25 
      3        9 
      4        3 
      5        1 
      6        3 
      7        2 
      8        2 

具有零參數的類是具體策略類或通過向外部系統發送數據來響應事件的類。

那些5或6個參數都有點不雅，可以使用一些重構來簡化它們。

帶有7或8個參數的四個類是God objects的絕佳示例。他們應該被分解，並且每個都已經在系統內的故障點列表中。

其餘的類（1到4個參數）（大部分）設計簡單，易於理解並符合single responsibility principle。

Answer 2

G'day George，

首先，對象之間的依賴關係是什麼？

很多「isa」關係？很多「哈薩克」的關係？

很多粉絲？或扇出？

喬治的迴應：「一直以來，一直試圖按照繼承建議的構成......爲什麼它會影響到？」

由於它主要是「哈薩」，你應該沒問題。

儘管爲了防止內存泄漏，最好確保組件的構造（和銷燬）正確完成。

而且，如果這是在C++中，請確保使用虛擬析構函數？

Answer 3

對許多依賴關係（可能超過8個）的需求可能表明設計缺陷，但總的來說，我認爲只要設計具有內聚性就沒有問題。

另外，考慮使用服務定位器或靜態網關來解決諸如日誌和授權等基礎設施問題，而不是混淆構造函數參數。

編輯：8可能是太多了，但我覺得會有它的奇怪的情況。看完李的帖子後，我同意，1-4通常是好的。

Answer 4

這是一個棘手的問題，爲什麼我喜歡混合方法，其中適當的屬性是可變的，只有不可變屬性和所需的依賴項沒有有用的默認值是構造函數的一部分。有些課程是根據要領構建的，如果需要的話可以通過制定者進行調整。

Answer 5

這一切都取決於您用於執行IOC的容器類型，以及容器使用註釋或配置文件來飽和待被對象化的對象所採用的方法。而且，如果你的構造函數參數只是普通的原始數據類型，那麼它並不是什麼大不了的;然而，如果你有非原始類型，那麼在我看來，你可以使用基於屬性的DI而不是基於DI的構造器。