默认构造函数是否应该将 NULL 传递给另一个构造函数来创建依赖项？答案

【问题标题】：Should default constructors pass NULLs to another constructor to create dependencies?默认构造函数是否应该将 NULL 传递给另一个构造函数来创建依赖项？
【发布时间】：2012-03-08 20:08:09
【问题描述】：

我有一堆具有一组依赖项的类。这个项目的依赖注入将是多余的，所以目前我们在许多情况下都有以下模式：

public MyClass() : this(null, null) {}

public MyClass(Dependancy x, Dependancy y)
{
  this.x = x ?? new Dependancy();
  this.y = y ?? new Dependancy();
}

我不喜欢这段代码，但我不完全确定为什么。一个原因是它会修改传入的参数，另一个是我可能希望参数为空，并保持为空。

是否有充分的理由避免/使用这种模式或任何其他模式，或者它基本上只是个人喜好？

【问题讨论】：

标签： c# dependency-injection constructor dependencies

【解决方案1】：

您发布的代码的问题是您正在使用依赖注入，而您只是不使用控制反转。 MyClass 将其依赖项注入其中，但如果它们不符合预期，它会控制要做什么。不愉快的原因有几个：

高层类MyClass耦合到低层类Dependency。
MyClass 充当 ServiceLocator，这本身就是一种反模式，但也违反了单一职责原则。
无参数构造函数有隐藏的副作用；使用它的地方在不知不觉中构造了MyClass，其依赖项都设置为Dependency。

正如@Alessandro Santini 所说，我真的鼓励你放弃这个并使用 DI / IoC 容器。至少摆脱无参数构造函数并强制任何想要构造MyClass 实例的东西为其提供适当的依赖项。如果给定的依赖项为空，则双参数构造函数应该抛出异常。

【讨论】：

很好，我希望每个人都这么说！谢谢

【解决方案2】：

你不喜欢它有两个原因：

不需要有一个参数化的构造函数来传递 NULL；有第二个无参数构造函数；
与好处相比，拥有第三个类（命名为 Factory，命名为 Container，没关系）注入这些默认依赖项永远不会过大。

【讨论】：

+1 DI 从不矫枉过正。也许您不需要容器，但模式本身总是比在黑暗中新建依赖项更好。