c# - 是否应该避免使用静态类，因为它使依赖注入变得困难？

Question

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

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

我想我可以使用 TypeMock 将它们存根，但我宁愿免费做。

你怎么看？

编辑

如果您认为它们不难测试，您能否举例说明如何测试它们。这些静态类实例化其他类型来完成它们的功能。

Answer 1

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

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

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

正如您提到的，在这个问题的第一个答案中是反对静态类的论点。

Answer 2

修改这些静态类以利用依赖注入有多难？如果您将 DI 设为可选（如果可能），则基本上可以通过正确执行 DI 来使用静态类进行模拟，同时不更改任何“正常”行为。

Answer 3

以下摘自《对象技术杂志》：将职责与静态方法分离以实现细粒度可配置性

静态方法通过硬连线实例创建对测试的开发造成障碍。对开源 Smalltalk 代码中的 120 个静态方法的研究表明，在 120 个静态方法中，只有 6 个不能同样很好地实现为实例方法，但事实并非如此，因此给调用者带来了对这些静态方法的隐式依赖的负担