是否应避免使用静态类，因为它会导致dependency injection困难？

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

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

我想我可以使用TypeMock将这些存在，但我宁愿免费使用它。

你怎么看？

编辑

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

Answer 1

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

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

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

在这个问题的第一个答案中是你提到的反对静态类的参数。

Answer 2

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

Answer 3

以下是来自对象技术期刊：将静态方法与细粒度可配置性分离的责任

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