应该避免使用静态类，因为它会使依赖注入困难吗？

Question

负责创建“Core”库的人创建了一组静态类，提供了各种实用程序，包括日志记录，审计和常见的数据库访问方法。

我个人认为这很糟糕，因为我们现在有一组很难测试的Core库，因为我不能模拟/存根这些类或者对它们的构造函数进行任何注入。

我想我可以使用TypeMock来解决这些问题，但我宁愿免费使用它。

您怎么看？

修改

如果你不认为他们很难测试，你可以给出一个如何测试它们的例子。这些静态类实例化其他类型来完成它们的功能。

Answer 1

静态类（方法）不一定要避免，只要它们没有隐藏的依赖关系。当然，您可以将依赖项传递给静态方法 - 它不应该存储在内部并修改以后调用的行为 在这种情况下测试它们应该没有问题。

但我对你提到的案例也有不好的看法。我知道其中一些静态的“包装器”实用程序类 - 在大多数情况下它们确实很臭：）

修改：
也许我应该澄清一下。我会将静态类/方法仅用于非常小的区分任务。当静态类开始初始化依赖项时，它们当然应该避免。如果你无法测试这些静态类，那么他们已经有了太大的工作要做。

在first answer of this question中是你提到的反对静态类的参数。

Answer 2

修改这些静态类以使用依赖注入有多难？如果你将DI作为可选项（如果可能的话），你实际上可以通过正确地执行DI来使用静态类进行模拟，同时不改变任何“正常”行为。

Answer 3

以下来自Journal of Object Technology: Decoupling responsibilities from static methods for fine-grained configurability

  

静态方法通过硬连线实例创建对测试的开发造成障碍。对开源Smalltalk代码中的120种静态方法的研究表明，在120种静态方法中，只有6种方法不能像实例方法那样实现，但却没有，因此给它们的调用者增加了对这些静态方法的隐式依赖性< / p>