如果我正在编写一个具有多个构造函数参数的类,例如:
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 容器我可以为依赖项配置构造函数并解决它们,因此当构造函数需要更改时影响最小。
这是否被视为反模式和/或反对这样做的任何论点?
最佳答案
这确实为您的依赖项似乎是可选打开了大门。通过为 AArgs 类的每个依赖项提供属性,有人会认为他们只需要填写 Dependency1,一切都会按预期工作。
通过显式单独列出所有依赖项,您可以清楚地了解类运行所需的条件。如果你有太多的依赖关系以至于构造函数很麻烦,那应该被认为是一种气味,因为你的类可能做的太多了。
关于c# - 构造函数 + 依赖注入(inject),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2549173/