構造函數+依賴注入

Question

如果我要編寫一個包含多個構造函數參數的類，例如：

class A{
    public A(Dependency1 d1, Dependency2 d2, ...){}
}

我通常會創建一個“參數持有人”類型的類，例如：

class AArgs{
    public Dependency1 d1 { get; private set; }
    public Dependency2 d2 { get; private set; }
    ...
}

接着：

class A{
    public A(AArgs args){}
}

通常，使用DI容器，我可以為依賴項配置構造函數並解決它們，因此在需要更改構造函數時，影響最小。

這是否被視為反模式和/或反對這樣做的任何論點？

Answer 1

這確實為您的依賴項是可選的打開了大門。 通過為AArgs類的每個依賴項都具有屬性，某人可以認為他們只需要填寫Dependency1，一切都會按預期進行。

通過顯式地單獨列出所有依賴項，可以明確約定類正常運行所需的條件。 如果您有太多的依賴關系，以至於構造函數很繁瑣，則應將其視為一種氣味，因為您的類可能做得太多。

Answer 2

Mark Seemann對此發表了博客 。

您正在傳遞的是依賴關系的集合，而不是每個依賴關系本身，基本上是重構。 馬克（Mark）辯稱，通過這樣做，您可以使域中的事物變得顯式，而以前是隱式的。

Answer 3

我唯一關心的是，依賴項持有AArgs可能掩蓋了您擁有大量依賴項這一事實，因此您正在構造的類可能承擔了太多責任。

如果您的依賴關系持有AArgs通常只有很少的成員（例如3個或更少），那么這不是問題。

Answer 4

好吧，我不會稱其為反模式，但是如果開發人員需要對您的代碼庫進行更改，則會弄清楚構造函數的需求，因此“為了安全”只需將所有依賴項對象傳遞給構造函數即可。 kes！ 它是那些可能被濫用的抽象之一。