构造函数+依赖注入

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容器我可以配置依赖关系的构造函数＆amp;解决他们＆amp;所以当构造函数需要改变时，影响最小。

这是否被视为反模式和/或反对这样做的任何论据？

Answer 1

这确实为您的依赖项可选打开了大门。通过为您的AArgs类提供每个依赖项的属性，有人可以认为他们只需要填写Dependency1，一切都将按预期工作。

通过单独明确列出所有依赖项，您可以明确地了解类的运行所需的内容。如果你有很多依赖项，构造函数很麻烦，那应该被视为一种气味，因为你的班级可能做得太多了。

Answer 2

马克·西曼对此有blogged的看法。

你传递的是依赖关系的集合，而不是每个依赖关系 - 基本上它是一个重构。 Mark认为，通过这样做，您可以在您的域中明确显示以前隐含的内容。

Answer 3

我唯一担心的是你的依赖关系持有者类AArgs可能会掩盖你有大量依赖关系的事实，因此你正在构建的类可能有太多的责任。

如果您的依赖关系持有者类AArgs通常只有很少的成员（例如，3个或更少），那么这不是问题。

Answer 4

好吧，我不会把它称为反模式，但如果开发人员需要对你的代码库进行更改，那么弄清楚构造函数需要什么就会很困惑，所以“只是为了安全“他们可以将所有依赖项对象传递给构造函数。 哎呀！它是其中一个可能被滥用的抽象。