I metodi statici impliciti possono causare problemi?

Dovresti leggere questo articolo sulla regola di analisi del codice # CA1822, che afferma:

Members that do not access instance data or call instance methods can be marked as static (Shared in Visual Basic). After you mark the methods as static, the compiler will emit nonvirtual call sites to these members. Emitting nonvirtual call sites will prevent a check at runtime for each call that makes sure that the current object pointer is non-null. This can achieve a measurable performance gain for performance-sensitive code. In some cases, the failure to access the current object instance represents a correctness issue.

I metodi statici sono in genere operazioni di utilità condivise tra istanze di una classe specifica, a.k.a metodi di utilità. Ad esempio il metodo String.Join() che accetta una matrice e unisce gli elementi utilizzando un carattere separatore o una stringa.

Quindi, la mia regola è che se il metodo è una funzionalità condivisa dell'utilità specifica per le istanze di quella classe, allora può essere statica.

Sarebbe strano dover creare un nuovo string per utilizzare il metodo Join() per unire più stringhe in una nuova.

Questa è un'opinione piuttosto che dei fatti concreti, la presento qui perché potrebbe essere d'aiuto. eccolo:

Una preoccupazione principale per la statica è la sicurezza dei thread. I campi statici all'interno delle classi statiche (piuttosto che i metodi statici stessi) possono causare risultati imprevisti quando più thread sono in azione.

Is there any benefit to calling a static method over an instance method?

Sì, supponendo che il metodo utilizzi una variabile di istanza di qualche tipo come un contatore, ad esempio, se si esegue questa operazione si è certi che le variabili utilizzate all'interno del metodo di istanza verranno allocate separatamente per ciascun oggetto. Puoi scegliere di bloccare il tuo oggetto e i risultati dovrebbero essere corretti quando più thread accedono ad esso.

why doesn't the compiler implicitly convert this to a static method?

Non so davvero quale sia il compilatore, ma se non trasforma questi metodi in metodi statici, una ragione potrebbe essere dovuta alla sicurezza dei thread. Questo perché, il compilatore dovrà modificare il codice con i blocchi per farlo restituire il risultato corretto. Le serrature rallentano l'esecuzione nell'elaborazione con pacciamatura.

Modifica: risolto un tipo come suggerito dal commento di @ WinstonEwert.

Poiché il tuo metodo non è definitivo (sealed) né privato, significa che potrebbe essere sovrascritto da una classe child, che è almeno una ragione per cui il compilatore non può trasformare quel metodo in un metodo statico.

Ora, se lo rendi privato o definitivo (sigillato), non c'è motivo di non renderlo statico, ma il miglioramento delle prestazioni sarebbe minimo, dal momento che passa solo un parametro in meno (non c'è bisogno di chiamate virtuali se il metodo è privato e / o finale) Inoltre, come ha detto Bernard, rimuoverebbe anche il controllo null sull'istanza, che potrebbe comunque verificarsi anche con un metodo privato o protetto.

Ad esempio con questo codice:

public static staticMethod() {
    MyClass class= ...
    class.FormatColumn("a", 1) // this should throw an exception if column is null, but not when FormatColumn becomes static
}

per un metodo privato, immagino che il compilatore possa controllare tutte le chiamate da un metodo statico e aggiungere i necessari controlli del puntatore nullo, dato che ha accesso all'intera classe, ma probabilmente dovremmo perdere in salti ciò che abbiamo salvato aggiungendo un puntatore aggiuntivo a this .