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

Question

有人被赋予创建“核心”库的任务，他们创建了一组静态类，提供各种实用程序，包括日志记录、审计和常见的数据库访问方法。

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

我想我可以使用TypeMock来存根它们，但我宁愿免费做到这一点。

你怎么看？

编辑

如果你不认为它们难以测试，你能否举一个如何测试它们的例子。这些静态类实例化其他类型来执行它们的功能。

- Ryu

---

我并不认为某些特定类型的静态方法本质上有什么邪恶之处，只要它们是引用透明的，没有隐藏的依赖关系、没有副作用等。问题在于，在大多数情况下，这些方法会导致低内聚性。它们可能属于其他地方，比如域对象或服务等。 - sara

Answer 1

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

但是，我对您提到的情况感到不安。我知道一些这样的静态“包装器”实用程序类 - 在大多数情况下，它们真的很糟糕 :)

编辑：也许我应该澄清一下。我只会将静态类/方法用于非常小的区分任务。当静态类开始初始化依赖项时，它们肯定应该被避免。如果您无法测试这些静态类，则它们已经有太大的工作量。

在此问题的第一个回答中，列出了您提到的反对使用静态类的论点。

- tanascius

Answer 2

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

静态方法通过硬编码实例创建，给测试开发带来了障碍。对120个开源Smalltalk代码中的静态方法进行研究表明，在这120个静态方法中，只有6个不能同样地实现为实例方法，但它们没有这样做，从而使调用者承担了对这些静态方法的隐式依赖。

- LCJ

Answer 3

修改那些静态类以利用依赖注入会有多难？如果您使 DI 可选（如果可能的话），您可以基本上创建一种情况，即通过正确进行 DI，您可以使用静态类进行模拟，而不更改任何“正常”行为。

- Paul Sonier