Vantaggi dell'uso di metodi statici privati

Quando si crea una classe con metodi privati ​​interni, di solito per ridurre la duplicazione del codice, che non richiede l'uso di campi di istanza, ci sono vantaggi in termini di prestazioni o memoria nel dichiarare il metodo come statico?

Esempio:

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;
}

C'è qualche vantaggio nel dichiarare i metodi GetInnerXml () come statici? Nessuna risposta d'opinione per favore, ho un'opinione.

Dalla pagina della regola FxCop su questo:

Dopo aver contrassegnato i metodi come statici, il compilatore emetterà siti di chiamata non virtuali a questi membri. L'emissione di siti di chiamata non virtuali impedirà un controllo in fase di esecuzione per ogni chiamata che garantisce che il puntatore dell'oggetto corrente sia non nullo. Ciò può comportare un aumento delle prestazioni misurabile per il codice sensibile alle prestazioni. In alcuni casi, il mancato accesso all'istanza dell'oggetto corrente rappresenta un problema di correttezza.

Quando scrivo una classe, la maggior parte dei metodi rientra in due categorie:

• Metodi che utilizzano / modificano lo stato dell'istanza corrente.
• Metodi di supporto che non usano / cambiano lo stato dell'oggetto corrente, ma mi aiutano a calcolare i valori di cui ho bisogno altrove.

I metodi statici sono utili, perché solo osservando la sua firma, sai che la chiamata non utilizza o modifica lo stato dell'istanza corrente.

Prendi questo esempio:

Biblioteca di classe pubblica
{
    Trova libro statico privato (Elenco libri <Libro>, titolo stringa)
    {
        // il codice va qui
    }
}

Se un'istanza dello stato della biblioteca viene rovinata, e sto cercando di capire perché, posso escludere findBook come colpevole, proprio dalla sua firma.

Cerco di comunicare il più possibile con la firma di un metodo o di una funzione, e questo è un modo eccellente per farlo.

Una chiamata a un metodo statico genera un'istruzione call nel linguaggio intermedio Microsoft (MSIL), mentre una chiamata a un metodo di istanza genera un'istruzione callvirt, che verifica anche la presenza di riferimenti a oggetti null. Tuttavia, il più delle volte la differenza di prestazioni tra i due non è significativa.

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

Sì, il compilatore non ha bisogno di passare il thispuntatore implicito ai staticmetodi. Anche se non lo usi nel tuo metodo di istanza, viene comunque passato.

Sarà leggermente più veloce in quanto non viene passato questo parametro (anche se il costo delle prestazioni per chiamare il metodo è probabilmente molto più di questo risparmio).

Direi che il miglior motivo a cui riesco a pensare per i metodi statici privati ​​è che significa che non puoi cambiare accidentalmente l'oggetto (dato che non c'è questo puntatore).

Questo ti costringe a ricordare di dichiarare anche tutti i membri con ambito di classe utilizzati dalla funzione come statici, il che dovrebbe salvare la memoria della creazione di quegli elementi per ogni istanza.

Preferisco di gran lunga che tutti i metodi privati ​​siano statici a meno che non possano davvero esserlo. Preferirei di gran lunga quanto segue:

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;
    }
}

su ogni metodo che accede al campo dell'istanza. Perchè è questo? Perché quando questo processo di calcolo diventa più complesso e la classe finisce con 15 metodi di supporto privati, allora VERAMENTE voglio essere in grado di estrarli in una nuova classe che incapsula un sottoinsieme dei passaggi in modo semanticamente significativo.

Quando si MyClassottengono più dipendenze perché è necessario il log e occorre anche avvisare un servizio Web (si prega di scusare gli esempi di cliché), è davvero utile vedere facilmente quali metodi hanno quali dipendenze.

Strumenti come R # ti consentono di estrarre una classe da una serie di metodi statici privati ​​in pochi tasti. Prova a farlo quando tutti i metodi di supporto privati ​​sono strettamente associati al campo dell'istanza e vedrai che può essere piuttosto un mal di testa.

Come è già stato affermato, i metodi statici presentano numerosi vantaggi. Però; tieni presente che vivranno sul mucchio per la vita dell'applicazione. Di recente ho trascorso un giorno a rintracciare una perdita di memoria in un servizio di Windows ... la perdita era causata da metodi statici privati ​​all'interno di una classe che implementava IDisposable e veniva costantemente chiamata da un'istruzione using. Ogni volta che questa classe veniva creata, la memoria veniva riservata sull'heap per i metodi statici all'interno della classe, sfortunatamente, quando la classe veniva eliminata, la memoria per i metodi statici non veniva rilasciata. Ciò ha causato il footprint di memoria di questo servizio di consumare la memoria disponibile del server entro un paio di giorni con risultati prevedibili.