プライベート静的メソッドを使用する利点

内部プライベートメソッドを持つクラスを作成するとき、通常はコードの重複を減らし、インスタンスフィールドを使用する必要はありませんが、メソッドをstaticとして宣言することにはパフォーマンスやメモリの利点がありますか？

例：

foreach (XmlElement element in xmlDoc.DocumentElement.SelectNodes("sample"))
{
    string first = GetInnerXml(element, ".//first");
    string second = GetInnerXml(element, ".//second");
    string third = GetInnerXml(element, ".//third");
}

...

private static string GetInnerXml(XmlElement element, string nodeName)
{
    return GetInnerXml(element, nodeName, null);
}

private static string GetInnerXml(XmlElement element, string nodeName, string defaultValue)
{
    XmlNode node = element.SelectSingleNode(nodeName);
    return node == null ? defaultValue : node.InnerXml;
}

GetInnerXml（）メソッドを静的として宣言する利点はありますか？意見の回答はありません、私は意見があります。

これに関するFxCopルールページから：

メソッドを静的としてマークすると、コンパイラーはこれらのメンバーに非仮想呼び出しサイトを発行します。非仮想呼び出しサイトを発行すると、現在のオブジェクトポインタがnullでないことを保証する各呼び出しの実行時のチェックが防止されます。これにより、パフォーマンスの影響を受けやすいコードで測定可能なパフォーマンスが向上する可能性があります。場合によっては、現在のオブジェクトインスタンスへのアクセスの失敗は、正確性の問題を表します。

クラスを作成しているとき、ほとんどのメソッドは2つのカテゴリに分類されます。

• 現在のインスタンスの状態を使用/変更するメソッド。
• 現在のオブジェクトの状態を使用/変更しないが、他の場所で必要な値を計算するのに役立つヘルパーメソッド。

静的メソッドは便利です。そのシグネチャを見るだけで、その呼び出しは現在のインスタンスの状態を使用または変更しないことがわかります。

この例を見てみましょう：

パブリッククラスライブラリ
{
    private static Book findBook（List <Book> books、string title）
    {
        //ここにコードが入ります
    }
}

ライブラリの状態のインスタンスがめちゃくちゃになり、その理由を解明しようとしている場合は、findBookをその署名から除外することができます。

メソッドや関数のシグネチャを使ってできる限り多くのことをやり取りしようとしていますが、これはそのための優れた方法です。

静的メソッドの呼び出しは、Microsoft中間言語（MSIL）で呼び出し命令を生成しますが、インスタンスメソッドの呼び出しは、nullオブジェクト参照をチェックするcallvirt命令を生成します。ただし、ほとんどの場合、2つの間のパフォーマンスの違いは重要ではありません。

src：MSDN- http ://msdn.microsoft.com/en-us/library/79b3xss3(v= vs.110).aspx

はい、コンパイラは暗黙のthisポインタをstaticメソッドに渡す必要はありません。インスタンスメソッドで使用しなくても、渡されます。

このパラメーターが渡されないため、少し高速になります（ただし、メソッドを呼び出すことによるパフォーマンスコストは、おそらくこの節約よりもかなり高くなります）。

プライベート静的メソッドについて考えることができる最も良い理由は、誤ってオブジェクトを変更できないことを意味します（このポインターがないため）。

これにより、関数が静的として使用するクラススコープのメンバーも宣言することを忘れないでください。これにより、インスタンスごとにこれらのアイテムを作成するメモリを節約できます。

私は、すべてのプライベートメソッドが静的にできない場合を除いて、静的であることを強く望んでいます。私は次のことを望みます：

public class MyClass
{
    private readonly MyDependency _dependency;

    public MyClass(MyDependency dependency)
    {
        _dependency = dependency;
    }

    public int CalculateHardStuff()
    {
        var intermediate = StepOne(_dependency);
        return StepTwo(intermediate);
    }

    private static int StepOne(MyDependency dependency)
    {
        return dependency.GetFirst3Primes().Sum();
    }

    private static int StepTwo(int intermediate)
    {
        return (intermediate + 5)/4;
    }
}

public class MyDependency
{
    public IEnumerable<int> GetFirst3Primes()
    {
        yield return 2;
        yield return 3;
        yield return 5;
    }
}

インスタンスフィールドにアクセスするすべてのメソッド。どうしてこれなの？この計算プロセスがより複雑になり、クラスの最後に15個のプライベートヘルパーメソッドができるので、ステップのサブセットを意味的に意味のある方法でカプセル化する新しいクラスにそれらを本当に引き出したいと思っています。

いつ MyClass私たちがロギングを必要とし、また（決まり文句の例を言い訳してください）Webサービスを通知する必要があるため、より多くの依存関係を取得し、それは簡単な方法は、その依存関係を持っているものを見るために本当に便利です。

R＃などのツールを使用すると、いくつかのキーストロークで一連のプライベート静的メソッドからクラスを抽出できます。すべてのプライベートヘルパーメソッドがインスタンスフィールドに密接に結合されているときに実行してみてください。

すでに述べたように、静的メソッドには多くの利点があります。しかしながら; アプリケーションの存続期間中、ヒープ上に存在することを覚えておいてください。私は最近、Windowsサービスのメモリリークを追跡するのに1日を費やしました...このリークは、IDisposableを実装し、usingステートメントから一貫して呼び出されたクラス内のプライベート静的メソッドによって引き起こされました。このクラスが作成されるたびに、クラス内の静的メソッドのためにヒープ上にメモリが予約されましたが、残念ながら、クラスが破棄されても、静的メソッドのメモリは解放されませんでした。これにより、このサービスのメモリフットプリントが数日以内にサーバーの使用可能なメモリを消費し、予測可能な結果が得られました。