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

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

我想我可以用打字模型把这些删掉，但我宁愿免费做。

你怎么认为？

编辑

如果你不认为它们很难测试，你能举个例子说明你将如何测试它们吗？这些静态类实例化其他类型来完成它们的功能。

只要静态类(方法)没有隐藏的依赖项，就不必避免它们。当然，您可以将依赖项传递到静态方法中——它不应该存储在内部，也不应该修改以后调用的行为。在这种情况下，测试它们也应该没有问题。

但我对你提到的案件也有不好的感觉。我知道一些静态的"包装器"实用程序类——在大多数情况下，它们真的很糟糕：)

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

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

以下是来自《对象技术杂志》：将责任从静态方法中分离出来？新硬币？可操作性

Static methods pose obstacles to the development of tests by hardwiring instance creation. A study of 120 static methods in open-source Smalltalk code shows that out of the 120 static methods, only 6 could not equally well be implemented as instance methods, but were not, thus burdening their caller with the implicit dependency on these static methods

修改这些静态类以利用依赖注入有多困难？如果您使DI成为可选的(如果可能的话)，那么您基本上可以在不改变任何"正常"行为的情况下，通过正确地执行DI，使用静态类进行模拟。