为什么静态变量被认为是邪恶的？

Question

为什么静态变量被认为是邪恶的？我是一个Java程序员谁是新的企业世界。最近，我开发了一个应用程序Groovy还有爪哇。在我编写的代码中，使用了相当多的静力学。高级技术部要求我减少使用静力学的数量。我在谷歌上搜索过类似的内容，我发现很多程序员都相当反对使用静态变量。我发现静态变量更便于使用。而且我认为它们也是有效的(如果我错了，请纠正我)，因为如果我必须在类中调用10，000个函数，我很乐意将方法静态化，并使用简单明了的方法。Class.methodCall()而不是用类的10，000个实例凌乱内存，对吗？此外，静力学减少了对代码其他部分的相互依赖。他们可以充当完美的州持有者。此外，我发现静力学在一些语言中得到了广泛的实现，例如小谈话和斯卡拉。那么，为什么这种对静力学的压迫在程序员中很普遍(尤其是在Java世界中)？PS：如果我对静力学的假设是错误的，请纠正我。

Answer 1

静态变量表示全局状态。这很难推理，也很难测试：如果我创建一个对象的新实例，我可以在测试中推理它的新状态。如果我使用静态变量的代码，它可能处于任何状态，而且任何东西都可以修改它。

我可以继续讲很长一段时间，但更大的概念是，事物的范围越窄，推理就越容易。我们善于思考小事情，但如果没有模块化，就很难对一百万行系统的状态进行推理。顺便说一句，这适用于各种事物-不仅仅是静态变量。

Answer 2

它不太面向对象：有些人认为静力学是“邪恶”的原因之一是它们与面向对象范式。特别是，它违反了数据封装在对象(可以扩展、信息隐藏等)中的原则。静力学，以你描述的方式使用它们，本质上是将它们作为一个全局变量来使用，以避免处理像范围这样的问题。然而，全局变量是过程或命令式编程范式的定义特征之一，而不是面向对象代码的“好”特性。这并不是说过程范式是糟糕的，但我得到的印象是，您的主管希望您编写“良好的面向对象的代码”，并且您确实希望编写“良好的过程代码”。

当您开始使用静力学时，Java中有许多问题并不总是显而易见的。例如，如果程序的两个副本运行在同一个VM中，那么它们会不会SHRE静态变量的值和彼此状态的混乱？或者当您扩展类时，可以覆盖静态成员吗？您的VM是否因为有大量的静力学而耗尽内存，并且无法为其他所需的实例对象回收内存？

对象生命周期：此外，静力学的生命周期与程序的整个运行时相匹配。这意味着，即使使用完类，也不能垃圾收集所有这些静态变量的内存。例如，如果您将变量设置为非静态变量，并且在main()函数中创建了类的单个实例，然后要求类执行特定函数10，000次，一旦完成这10，000次调用，并且删除对单个实例的引用，则可以垃圾收集和重用所有静态变量。

防止某些重复使用：此外，静态方法不能用于实现接口，因此静态方法可以阻止某些面向对象的特性可用。

其他备选方案：如果效率是您最关心的问题，那么可能还有其他更好的方法来解决速度问题，而不是仅仅考虑调用通常比创建更快的优点。考虑是否在任何地方都需要瞬态或易失性修饰符。为了保持内联的能力，方法可以标记为Final而不是静态的。方法参数和其他变量可以标记为Final，以允许基于可以更改这些变量的假设进行某些编译器优化。可以多次重用实例对象，而不是每次创建新实例。可能会有复杂优化开关，应该打开的应用程序在一般情况下。也许，设计应该设置，这样就可以运行10，000次多线程，并利用多处理器内核。如果可移植性不是一个问题，也许一个本地的方法会让你比你的静力学更快。

如果由于某种原因不希望一个对象的多个副本，则单例设计模式，与静态对象相比具有优势，例如线程安全(假定您的单例代码编写得很好)、允许延迟初始化、确保对象在使用时被正确初始化、子类化、测试和重构代码方面的优势，更不用说，如果您在某一时刻改变了只想要一个对象实例的想法，那么删除代码以防止重复实例要比重构所有静态变量代码以使用实例变量容易得多。我以前不得不这样做，这并不有趣，最后你不得不编辑更多的类，这就增加了引入新bug的风险…所以最好在第一次设置“正确”的东西，即使它似乎有它的缺点。对我来说，如果你决定在路上需要多个副本的话，你所需要的返工可能是尽可能不经常使用静力学的最有说服力的原因之一。因此，我也不同意你所说的静力学减少相互依赖的说法，我认为，如果你有很多可以直接访问的静力学，而不是一个“知道如何在自己身上做某事”的对象，你最终会得到更多耦合的代码。

Answer 3

邪恶是一个主观的术语。

你不能在创造和毁灭方面控制静力学。他们是按程序装卸的要求生活的。

由于静力学存在于一个空间中，所有希望使用它们的线程都必须通过您必须管理的访问控制。这意味着程序更加耦合，这一变化更难以设想和管理(如J·斯基特所说)。这会导致隔离更改影响的问题，从而影响测试的管理方式。

这是我对它们的两个主要问题。