构造函数+依赖注入

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！ 它是那些可能被滥用的抽象之一。