ReSharper抱怨方法何时可以是静态的，但不是静态的

当一种方法可以变成静态方法时，为什么ReSharper会抱怨呢？

是因为仅创建了一个静态方法的实例（在类型上），从而节省了性能？

我发现该评论非常有用，因为它指出了两个重要的事项：

1. 这使我问自己，所讨论的方法是否实际上应该属于该类型的一部分。由于它不使用任何实例数据，因此至少应考虑是否可以将其移动到自己的类型。它是该类型的组成部分，还是真的是通用实用程序方法？

2. 如果将方法保持在特定类型上确实有意义，则可能会提高性能，因为编译器将为静态方法发出不同的代码。

从FxCop文档获得相同的警告（强调）：

“不访问实例数据或调用实例方法的成员可以标记为静态（在Visual Basic中为Shared）。将方法标记为静态后，编译器将向这些成员发出非虚拟调用站点。发出非虚拟调用站点将阻止在运行时检查每次调用，以确保当前对象指针不为空，这可能会导致性能敏感代码的性能得到可衡量的提高。在某些情况下，无法访问当前对象实例表示正确性问题。 ”

关于这个主题的很好的辩论（SO）。我在可以使静电成为静态的阵营中。我之所以这样认为，是因为为什么会有一个不使用任何实例数据的实例方法。在这种情况下，它是真正的实例方法还是实际上是类方法？

如果将方法声明为静态，则无需创建该类的实例（零个）来使用该方法...这样可以节省垃圾回收器从回收对象中回收对象时进行构造处理，堆空间和cpu循环所需的cpu循环。堆...

还有，你的问题，正如它写的

“ ...仅创建一个静态方法的实例（在类型上）...”

表示对于实例方法，该方法的代码将针对所创建的类的每个实例重复进行。那是不对的。无论为任何类型创建多少个实例，方法的代码都只会加载到内存一次。每个实例存储在堆中的对象仅存储类型的“状态”（非静态字段和一些其他跟踪变量）。

这不是投诉，而只是建议。

您不必为静态方法将“ this”压入函数的堆栈。这是它更便宜的另一个原因。

对我而言，此ReSharper建议的最大好处（您可以将其设置为警告，建议或提示）。是因为它鼓励我尽可能多地使方法静态化。这是一件好事，因为静态方法对它所属的类没有直接依赖。这意味着它可以轻松地作为静态成员移至另一个类。

ReSharper中使用静态方法的另一个巧妙技巧是通过使用“使方法静态化”重构使一组相关方法静态化。这会将一些依赖项移到方法参数中。以后查看这组方法时，可能会发现它们都访问特定类型的特定对象。然后，您可以使用“使方法成为非静态的”重构，并将该对象指定为新的this指针。这会将您的方法移至另一个类。

由此：

internal class ClassA
{
    public ClassB Property { get; set; }

    public int Method()
    {
        var classB = Property;
        return classB.Property1 + classB.Property2;
    }
}

internal class ClassB
{
    public int Property1 { get; set; }
    public int Property2 { get; set; }
}

对此：

    public static int Method(ClassB property)
    {
        var classB = property;
        return classB.Property1 + classB.Property2;
    }

对此：

internal class ClassA
{
    public ClassB Property { get; set; }
}

internal class ClassB
{
    public int Property1 { get; set; }
    public int Property2 { get; set; }

    public int Method()
    {
        return Property1 + Property2;
    }
}

静态在首次使用时被实例化，并将保留在内存中。如果不再使用，则可能是一个问题。静电很难测试（模拟等）。