全局静态类和方法不好吗？人们普遍认为，应该避免严重依赖全球资源。使用静态类和方法不是一回事吗？全球数据不好。但是，使用静态方法可以避免很多问题。我将采纳RichHickey在这个问题上的立场并解释如下：要使用C#构建最可靠的系统，请使用静态方法和类，而不是全局数据。例如，如果您将数据对象交给静态方法，而该静态方法不访问任何静态数据，您可以放心，给定输入数据，函数的输出将始终相同。这就是Erlang、Lisp、Clojure和其他所有函数式编程语言所采取的立场。使用静态方法可以大大简化多线程编码，因为如果编程正确，一次只有一个线程可以访问给定的数据集。这就是它归结为。拥有全局数据是不好的，因为它是一种可以随时被谁知道是什么线程更改的状态。但是，静态方法允许非常干净的代码，可以以较小的增量进行测试。我知道这将引起激烈的争论，因为它与C#的OOP思维过程相冲突，但我发现我使用的静态方法越多，我的代码就越清晰可靠。该视频比我解释得更好，但展示了不可变数据和静态方法如何导致一些极其线程安全的代码。让我澄清一些关于全球数据的问题。常量（或只读）全局数据不如可变（读/写）全局数据大。因此，如果拥有全局数据缓存有意义，请使用全局数据！在某种程度上，每个使用数据库的应用程序都会有这个，因为我们可以说所有的SQL数据库都是一个保存数据的大全局变量。所以像我上面那样做一个笼统的声明可能有点强烈。相反，假设拥有全局数据会引入许多使用本地数据可以避免的问题。一些语言，例如Erlang，通过将缓存放在一个单独的线程中来解决这个问题，该线程处理对该数据的所有请求。这样您就知道对该数据的所有请求和修改都是原始的，并且全局缓存不会处于某种未知状态。静态并不一定意味着全局。类和成员可以是静态私有的，因此只对特定类可用。也就是说，拥有太多公共静态成员而不是使用适当的方法来传递数据（方法调用、回调等）通常是糟糕的设计。如果您试图对您的OO开发保持纯粹，那么静态可能不适合这种模式。然而现实世界比理论更混乱，静态学通常是解决一些发展问题的非常有用的方法。在适当和适度的时候使用它们。可变静态变量不好，因为它们只是全局状态。我所知道的最好的讨论是在这里，标题为“为什么在不必要时应避免使用全局变量”。静态方法有几个缺点，往往使它们不受欢迎——最大的缺点是它们不能以多态方式使用。作为对其他内容的补充，finalstatic变量就可以了；常量是个好东西。唯一的例外是何时/是否应该将它们移动到属性文件中，这样更容易更改。首先，为什么旧??的全局变量如此糟糕？因为它是一种随时随地都可以进入的状态。难以追踪。静态方法没有这样的问题。这留下了静态字段（变量）。如果你在一个类中声明一个公共静态字段，那实际上是一个全局变量而且很糟糕。但是让静态字段保持私有，大部分问题就迎刃而解了。或者更好的是，它们仅限于包含类，这使得它们可以解析。公共类Foo{privatestaticintcounter=0;publicstaticintgetCounterValue(){返回计数器；}//...publicFoo(){//其他任务counter++;在上面的代码中，你可以看到我们统计了创建了多少个Foo对象。这在很多情况下都很有用。static关键字不是全局的，它告诉你它在类级别，这在各种情况下都非常有用。因此，总而言之，类级别的东西是静态的，对象级别的东西不是静态的。静态方法用于在Scala中实现特征。在C#中，扩展方法（静态）部分地完成了这个角色。正如DCI支持者所说，可见这是一种“多态性的高阶形式”。此外，静态方法可用于实现功能。这就是F#用来实现模块的东西。（和VB.NET。）函数对于（不出所料）函数式编程很有用。有时它们只是一种建模方式（如Math类中的“函数”）。C#又一次出现了。我认为全局变量的坏处在于具有全局状态的想法——变量可以在任何地方被操作，并且往往会在程序的远程区域引起意想不到的副作用。静态数据类似于全局变量，因为它们引入了一种全局状态。假设它们是无状态的，那么静态方法并没有那么糟糕。不完全的。static实际上决定了实例化的时间、地点和频率，而不是谁可以访问它。以上就是C#学习教程：全局静态类和方法不好吗？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
