我是一名Java程序员，刚进入企业界。最近我用Groovy和Java开发了一个应用程序。在我编写的所有代码中，都使用了相当多的静态元素。高级技术人员要求我减少使用的静态数据的数量。我在谷歌上搜索过相同的内容，我发现许多程序员都相当反对使用静态变量。
我发现静态变量使用起来更方便。而且我假定它们也是有效的(如果我错了请纠正我)，因为如果我必须在一个类中对一个函数进行10,000次调用，我将很高兴使方法静态，并在其上使用直接的class . methodcall()，而不是用10,000个类实例使内存混乱，对吗?
此外，静态减少了对代码其他部分的相互依赖。他们可以作为完美的国家持有者。除此之外，我还发现一些语言(如Smalltalk和Scala)广泛地实现了静态。那么为什么程序员普遍反对静态(尤其是在Java世界中)呢?
PS:如果我对静态数据的假设是错误的，请纠正我。
当前回答
如果我必须在一个类中对一个函数进行10,000次调用，我会 很高兴使方法静态和使用直接 使用class.methodCall()来代替内存中10,000的混乱 类的实例，对吧?
您必须平衡将数据封装到具有状态的对象中的需求，以及简单地计算某些数据上的函数的结果的需求。
此外，静态减少了对代码其他部分的相互依赖。
封装也是如此。在大型应用程序中，静态方法往往会产生意大利面条式的代码，并且不容易进行重构或测试。
其他答案也为反对过度使用静态数据提供了很好的理由。
其他回答
静态变量表示全局状态。这很难推理，也很难测试:如果我创建了一个对象的新实例，我就可以在测试中推理它的新状态。如果我使用使用静态变量的代码，它可以处于任何状态-任何东西都可以修改它。
我还可以继续讲很久，但更重要的概念是，事物的范围越窄，就越容易进行推理。我们擅长思考小事，但如果没有模块化，就很难推断出百万行系统的状态。顺便说一下，这适用于各种各样的东西——不仅仅是静态变量。
在我看来，你是在问静态变量，但你也在你的例子中指出了静态方法。
静态变量并不是邪恶的——它们被采用为全局变量，就像大多数情况下与最终修饰符结合的常量一样，但正如它所说的，不要过度使用它们。
静态方法又名实用方法。使用它们通常不是一个坏的做法，但主要的问题是它们可能阻碍测试。
作为一个伟大的java项目的例子，使用了大量的静态和做它的正确方式，请看看Play!框架。在SO中也有关于它的讨论。
与静态导入相结合的静态变量/方法也被广泛应用于方便java中声明性编程的库中，如:make it easy或Hamcrest。如果没有大量的静态变量和方法，这是不可能的。
所以静态变量(和方法)很好，但要明智地使用它们!
Static fields are de facto GC roots (see the How Garbage Collection Works section earlier in this chapter), which means they are never garbage-collected! For convenience alone, static fields and collections are often used to hold caches or share state across threads. Mutable static fields need to be cleaned up explicitly. If the developer does not consider every possibility (a near certainty), the cleanup will not take place, resulting in a memory leak. This sort of careless programming means that static fields and collections have become the most common cause of memory leaks!
简而言之，永远不要使用可变静态字段——只使用常量。如果您认为需要可变静态字段，请再三考虑!总有更合适的方法。
邪恶是一个主观的术语。
你不能从创建和破坏的角度来控制静态。他们按照程序的要求生活装卸。
由于静态对象存在于一个空间中，所有希望使用它们的线程都必须通过您必须管理的访问控制。这意味着程序更加耦合，这种变化更难想象和管理(就像J Skeet说的那样)。这导致了隔离变更影响的问题，从而影响了如何管理测试。
这是我对他们的两个主要问题。
以上所有答案都说明了为什么静态方法很糟糕。它们是邪恶的原因是因为它给人一种错误的印象，即你在编写面向对象的代码，而事实上你并不是。 这简直是邪恶。
