我有下面的構造我的課依賴注入OR配置對象？
public MyClass(File f1, File f2, File f3, Class1 c1, Class2 c2, Class3 c3)
{
..........
}
可以看出，它有6個參數。在看到這段代碼時，我的一位老年人說，我不應該傳遞6個參數，而應該傳遞一個配置對象。
我以這種方式編寫代碼，因爲最近我已閱讀「依賴注入」，其中說「類必須要求他們想要的東西」。所以我認爲傳遞一個配置對象將違背原則。
我對「依賴注入」的解釋是否正確？或者我應該接受我的資深建議？
「配置對象」是一個鈍的術語，適用於這種情況;它以純機械的意義來構建你的努力。目標是將你的意圖傳達給班級的消費者;讓我們重構一下。
具有衆多參數的方法或構造函數表明它們之間的鬆散關係。消費者通常必須做出更多推理才能理解API。 這3個檔案連同這三個檔次？這是沒有傳達的信息。
這是一個通過從隱式概念中提取顯式概念來創建更有意義且意圖揭示的接口的機會。例如，如果3個文件因爲用戶而相關，則UserFileSet參數將清楚地表示該文件。也許f1與c1,f2到c2和f3到c3有關。將這些關聯聲明爲獨立類將會減少參數數量並增加可從API派生的信息量。
最終，重構將高度依賴於您的問題域。不要以爲你應該創建一個對象來完成一個參數列表;嘗試沿着參數之間關係的輪廓進行重構。這總是會產生能夠反映解決問題的代碼，而不是用來解決問題的語言。
我第二個這個單詞:) – vulkanino 2010-10-08 16:50:25
我不認爲使用配置對象與使用依賴注入模式相矛盾。它更多的是關於注入依賴關係的形式，以及關於是否最好有一個需要20個參數或將這些參數組合到一個類中以使它們被捆綁在一起的函數（在本例中爲構造函數）的一般問題。
您仍然可以自由使用依賴注入，即通過某個工廠或容器構建配置對象，並在創建類的實例時將其注入構造函數。是否這是一個好主意還取決於具體情況，沒有銀子彈;）
在我們的項目中，只有一個配置對象，其中包含所有屬性。我對使用它的擔心是，我將不得不在我的構造函數中創建Class1，Class2和Class3的對象。這似乎違背了「依賴注入」原則。 – athena 2010-10-08 06:31:23
當然這是另一個問題如何Class1的對象等獲得創建，但是從類MyClass的角度來看，它們被注入了依賴關係，無論它們是單獨傳遞還是一起傳遞到對象中。在哪個構造函數中實例化Class1等 - 在配置對象的構造函數中？ – 2010-10-08 07:23:23
是的。所有需要的對象都在配置對象的構造函數中實例化。我很困惑，因爲我不明白如何使用配置對象與使用工廠不同。 – athena 2010-10-08 10:15:07
他如何建議實例化「配置」對象？總的來說，我認爲你的方法很好。但我有點擔心你將太多的事情傳遞給它。 – 2010-10-08 05:54:12
配置對象使用java Properties類。它需要一個.properties文件。 – athena 2010-10-08 06:34:23