C# 全局静态类和方法坏吗？

人们普遍认为，应该避免严重依赖全球资源。使用静态类和方法不是一回事吗？

不完全一样。静态实际上决定了什么时候、什么地方、多久实例化一次，而不是谁有权访问它。

Static

不一定意味着全局。类和成员可以是静态私有的，因此只应用于特定的类。也就是说，拥有太多的

公共静态
成员而不是使用适当的方式传递数据（方法调用、回调等）通常是不好的设计。
可变静态变量是不好的，因为它们只是全局状态。这是我所知道的最好的讨论

静态方法有几个缺点，往往使它们不受欢迎-最大的缺点是它们不能被多态使用。
如果你试图对你的OO开发保持纯粹，那么静态可能不适合这种模式

然而，现实世界比理论更混乱，静力学通常是解决一些开发问题的非常有用的方法。在适当的时候适度地使用它们。
我认为全局变量的坏处在于拥有全局状态变量的想法——这些变量可以在任何地方操作，并且往往会在程序的遥远区域造成意外的副作用

静态数据类似于全局变量，因为它们引入了一种全局状态。假设静态方法是无状态的，那么静态方法就没有那么糟糕了。
全局数据是糟糕的。但是，使用静态方法可以避免许多问题

我将在这个问题上采取的立场是这样解释的：

要用C语言构建最可靠的系统，请使用静态方法和类，但不要使用全局数据。例如，如果您将一个数据对象交给一个静态方法，而该静态方法不访问任何静态数据，那么您可以确信，给定输入数据，函数的输出将始终相同。这是Erlang、Lisp、Clojure和其他人采取的立场

使用静态方法可以大大简化多线程编码，因为如果编程正确，一次只有一个线程可以访问给定的数据集。这就是问题的症结所在。拥有全局数据是不好的，因为它是一种状态，谁知道哪个线程可以随时更改。但是，静态方法允许以较小的增量测试非常干净的代码

我知道这会引起激烈的争论，因为它与C#的OOP思想过程背道而驰，但我发现我使用的静态方法越多，我的代码越干净、越可靠

比我解释得更好，但展示了不可变数据和静态方法如何生成一些非常线程安全的代码


让我进一步澄清一些有关全球数据的问题。恒定（或只读）全局数据的问题远没有可变（读/写）全局数据那么大。因此，如果拥有数据的全局缓存是有意义的，请使用全局数据！在某种程度上，每个使用数据库的应用程序都会有这样的功能，因为我们可以说所有SQL数据库都是一个保存数据的巨大全局变量

所以，像我上面所说的那样做一个笼统的陈述可能有点强。相反，假设使用全局数据会带来许多问题，而使用本地数据可以避免这些问题

有些语言（如Erlang）通过将缓存放在单独的线程中来解决这个问题，该线程处理对该数据的所有请求。这样，您就知道对该数据的所有请求和修改都是原子的，全局缓存不会处于未知状态
 除了前面所说的之外，
最终静态变量也很好；常数是一件好事。唯一的例外是当/如果您应该将它们移动到属性文件中，以便更容易更改。
首先，为什么旧的全局变量如此糟糕？因为它是一个可以随时随地访问的状态。难以追踪

静态方法不存在这样的问题

这就留下了静态字段（变量）。如果在一个类中声明了一个public静态字段，那么这将是一个真正的全局变量，这将是不好的

但是将静态字段设置为私有，大多数问题都得到了解决。或者更好，它们被限制在包含类中，这使得它们是可解的
 静态方法用于在Scala中实现。在C#中，扩展方法（是静态的）在中实现该角色。正如DCI支持者所说，这可以被视为一种挑战

此外，还可以使用静态方法来实现函数。这就是F#用来实现的。函数对于函数式编程很有用（这并不奇怪）。有时候，它们只是建模的方式（比如类中的“函数”）。再说一遍，这里

在上面的代码中，您可以看到我们计算了创建了多少个Foo对象。这在许多情况下都很有用

static关键字不是全局的，它告诉您它在类级别上，这在各种情况下都非常有用。总之，类级的东西是静态的，对象级的东西不是静态的。
为什么说“回到过去”？你有什么理由认为今天人们不那么讨厌它吗。。。此外，它可能是社区wiki。全局状态很糟糕，但我们之所以有单例（这是一种变通方法，不是真正的解决方案）是因为它们至少依赖于惰性构造（在访问时初始化），从而避免了初始化顺序问题。这以及它们是对象的事实意味着我们可以对它们应用OOP技术，比如继承它们、使用多态性等等。这个问题似乎被过度编辑了。许多评论甚至都没有
public class Foo
{
    private static int counter = 0;

    public static int getCounterValue()
    {
         return counter;
    }
    //...
    public Foo()
    {
        //other tasks
        counter++;
    }
}