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

Question

我有一堆具有一组依赖关系的类。该项目的依赖注入将是过度的，因此目前我们在许多情况下都有以下模式：

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

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

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

是否有任何强有力的理由避免/使用此模式或任何其他模式，或者它基本上只是个人偏好？

Answer 1

你不喜欢它，原因有两个：

• 不需要传递NULL的参数化构造函数;有第二个no-args构造函数;
• 与好处相比，拥有第三个类（将其命名为Factory，将其命名为Container，无关紧要）注入这些默认依赖项将永远不会过度。

Answer 2

你发布的代码就是 使用依赖注入，你只是而不是使用Inversion of Control。 MyClass将依赖项注入其中，但如果它们不符合预期，则会控制该怎么做。这有几个原因令人不快：

1. 较高级别的课程MyClass与较低级别的课程Dependency相关联。
2. MyClass充当ServiceLocator，它本身就是一种反模式，但也违反了单一责任原则。
3. 无参数构造函数具有隐藏的副作用;使用它的地方在不知不觉中构建MyClass，其依赖项都设置为Dependency。

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