方法可以是静态的，但应该是静态的吗？

Question

方法可以是静态的，但应该是静态的吗？ReSharper喜欢指出每个ASP.NET页面可能是静态的多个函数。如果我把它们弄得静止不动对我有帮助吗？我是否应该使它们是静态的，并将它们移动到实用程序类中？

Answer 1

静态方法与实例方法 
10.2.5静态和实例成员C#语言规范解释了这种区别。通常，静态方法可以比实例方法提供非常小的性能增强，但只在一些极端的情况下(请参见这个答案有关这方面的更多细节)。

FxCop或代码分析中的规则CA 1822规定：

在[将成员标记为静态]之后，编译器将向这些成员发出非虚拟调用站点，这将防止在运行时对每个确保当前对象指针为非空的调用进行检查。这可能导致性能敏感代码的可测量性能提高。在某些情况下，访问当前对象实例的失败代表了一个正确性问题。

效用类
除非在设计中有意义，否则不应该将它们移动到实用程序类。如果静态方法与特定类型相关，如ToRadians(double degrees)方法与表示角度的类有关，该方法作为该类型的静态成员存在是有意义的(注意，这是一个复杂的示例，用于演示)。

Answer 2

在我看来，性能、名称空间污染等等都是次要的。问问自己什么是合乎逻辑的。该方法是对类型的实例进行逻辑操作，还是与类型本身相关？如果是后者，则将其作为一种静态方法。只有当它与不受您控制的类型相关时，才将其移动到实用程序类中。

有时，有些方法在逻辑上对实例进行操作，但不碰巧使用实例的任何一种状态尚未..例如，如果您正在构建一个文件系统，并且您已经得到了目录的概念，但您还没有实现它，那么您可以编写一个返回文件系统对象类型的属性，它将始终只是“file”-但是它在逻辑上与实例相关，因此应该是一个实例方法。如果要使方法变为虚拟的，这也很重要-您的特定实现可能不需要状态，但派生类可能需要。(例如，询问一个集合是否只读-您可能还没有实现该集合的只读形式，但它显然是集合本身的属性，而不是类型。)

Answer 3

我相信在您的情况下不会发生这种情况，但是我在一些代码中看到了一种“难闻”-我通过维护使用了大量的静态方法而不得不忍受这种情况。

不幸的是，它们是静态方法，假定了特定的应用程序状态。(当然，每个应用程序只有一个用户！)为什么不让用户类在静态变量中跟踪这一点？)它们被美化了访问全局变量的方式。他们也有静态构造函数(！)，这几乎总是一个坏主意。(我知道有几个合理的例外)。

但是，当静态方法分解出实际上不依赖于对象实例的状态的域逻辑时，它们是非常有用的。它们可以使您的代码更具可读性。

一定要把它们放在正确的地方。静态方法是否侵入地操作其他对象的内部状态？是否可以证明他们的行为属于其中一个类呢？如果你没有正确地区分关注点，你可能会在以后头痛。