但是，不应该过度使用创建静态实用程序方法？ 怎么避免呢？
随着时间的推移……在java项目中引入了大量的实用方法，以实现更复杂，更简单的任务。
当使用静态方法时，我们在代码中引入紧耦合，这使得我们的代码更难以测试，特别是如果实用方法非常复杂。
我只是觉得现在很难管理和测试这些实用程序。 请指导我避免使用这些实用程序方法，以及如何组织现有项目以删除所有STATIC实用程序。
你能帮我避免静态方法吗？
与现有的其他答案相矛盾： 静态方法很糟糕！
它们确实引入了强耦合。 是的，有些情况是可以接受的。 是的，您可以通过在内部使用可交换的策略在静态方法中创建接缝。 但作为一个经验法则，静态仍然很糟糕。
要回答这个问题，如何摆脱静态方法。 简单：将它们放在适当的对象上。 所有静力学都消失了。 我们改进了代码吗？ 还不多 如果我们更换
callToStaticMethod()
同
new X().callToNoLongerStaticMethod()
我们用构造函数调用替换了静态调用，这实际上只是另一个静态方法。 但是现在你的X只是另一个依赖项，所以你可以注入它：
class A{ private final X x; A(X aX){ x = aX; } }
注意：没有必要使用Spring或任何其他框架。 如果您希望它提供使用默认实现的构造函数。 如果您是纯粹主义者，请为X引入界面。
测试A而不依赖于X的实现变得微不足道且显而易见。 同样以任何方式替换X
使用大量静态方法没有任何问题。
静态方法是（或应该是，读取） 无状态的 ，这使它们成为最简单的测试方法 – 没有设置，只需调用它们。
你不需要嘲笑，因为没有可以处理的状态。
关于无状态，如果技术静态方法使用静态变量来存储状态，则它们可以是有状态的。 如果是这种情况，从良好的设计角度来看，它们应该使用实例变量转换为实例方法来存储状态，如果需要，使用单例模式。
静态实用方法并不是那么糟糕。 您可以隐藏静态调用背后的包私有策略。 考虑到测试用例属于同一个包，可以很容易地测试（和替换）。 而且，它使代码非常易读。 当然，静态实用程序方法的客户端仍然只能在其测试中使用一个实现。 所以这里有一些不灵活性。
波希米亚人在谈论国家时是对的。 如果您的静态实用程序已声明您正在执行错误操作。
关于您的问题：如果您想避免使用静态方法，可以使用spring框架并定义您在不同上下文中使用和测试的不同实用程序实现。 但是，在这种情况下，访问这些对象并不方便，因为必须首先获取对知道实用程序对象的上下文的引用。
一组属于一个类的静态实用程序方法没有错。 请参阅java.util.Collections 。 如果该类中对List进行操作的每个方法都将在List接口本身中指定，则它们必须由所有子类实现。 只要它们可以通过公共List方法实现，就没有问题。
当然，只要你开始向接口添加方法（或者在类的情况下，使方法公开）只是为了能够将function放在静态方法而不是类本身，那么你就走错了路。