Uso di metodi statici per implementare la logica all'interno di una classe

Questo sarebbe OK, purché tu abbia dei discendenti che condividono in modo significativo quella logica.

La cosa protetta è che invia un messaggio, aumenta le aspettative. E troppo spesso, dopo aver scavato, non trovo discendenti che usano quei membri protetti e sembra che fosse solo una questione di "nel caso in cui avrò bisogno di accedervi più tardi da un ipotetico futuro discendente" (che non ha mai visto la luce del giorno). Questo non va bene.

Qualsiasi utilizzo di protected dovrebbe adattarsi al modello di ereditarietà nel senso che rappresenta chiaramente una logica comune per tutte le classi di bambini. Quindi ha senso e aiuta il lettore a capire l'applicazione.

protected static sono una cosa strana da creare. Sospetto che tu voglia creare metodi private static . Essendo protected , il tuo commento " static method is not publicly exposed " non è corretto al 100%. Si può accedere tramite classe figlio come mostrato di seguito:

using System;

public class Program
{
    static void Main()
    {
        var x = new Demo2();
        Console.WriteLine(x.AppendSomeAttribute("We hacked it. ")); 
        // Prints "We hacked it. lol" 
    }
}

class Demo
{
    private string _someAttribute;
    public Demo(string someAttribute) => _someAttribute = someAttribute;

    public string AppendSomeAttribute(string textToAppendTo) =>
        AppendSomeAttribute(textToAppendTo, _someAttribute);

    protected static string AppendSomeAttribute(string txtToAppendTo, string someAttrbute) =>
        string.Concat(txtToAppendTo, someAttrbute);
}

class Demo2 : Demo
{
    public Demo2() : base("lol") {}

    public static string LetsHack(string textToAppendTo, string someAttribute) =>
        AppendSomeAttribute(textToAppendTo, someAttribute);
}

Si può vedere in azione, qui .

Questa è una pratica comune quando si scrivono classi sicure multi-thread, anche se normalmente eviterei l'ereditarietà il più possibile in tale classe. Se il metodo statico è completamente puro (privo di effetti collaterali), può essere richiamato dall'esterno dei blocchi mutex protetti, il che è un grande vantaggio quando si tenta di evitare i blocchi annidati.

Il caso d'uso principale (secondo la tua spiegazione) è di evitare l'uso di valori di istanza. Ma non vedo alcun motivo per mantenere il metodo come statico dopo che è stato sviluppato.

1. Sviluppa un metodo (non statico)
2. Inseriscilo in static per vedere se nel corpo del metodo compaiono errori, il che indica che stai utilizzando i valori di istanza.
3. Rimuovi static .

Sono tutto per i metodi intelligenti per il factcheck di qualcosa, ma non vedo alcun motivo per mantenere il tuo approccio intelligente ma insolito dopo aver confermato ciò che volevi.

Come argomento secondario, se già non riesci a tenere traccia dei valori usati in un metodo, probabilmente il metodo sta gestendo troppo per cominciare.

By removing the object's state from the equation the logic of these methods is more easily tested / proven; either by unit tests,

Non sto seguendo abbastanza qui. I metodi statici (da soli) sono notoriamente difficili da testare in quanto non è facile prendere in giro uno stato.

Una statica avvolta in una non-statica non è diversa da una configurazione non statica completa; in termini di test unitario.

All logic is handled in a single place; so where there are multiple public methods taking different parameters this helps keep all logic in one routine (definitely makes sense where the version of that routine which supplies all parameters is not supposed to be publicly exposed; otherwise I can't see a benefit).

Questo è un argomento per pubblico / protetto / privato, non statico / istanza. È possibile ottenere lo stesso identico obiettivo con metodi di istanze private / protette.

Semplicemente non vedo il punto del tuo codice. Nulla cambia se rimuovi la parola chiave static dal tuo esempio.

Nei tuoi commenti sul codice, dici che [protected] static method is not publicly exposed , che è un falso nome. non è esposto pubblicamente perché è protetto , indipendentemente dal fatto che sia statico o meno.

Se stai parlando di come un metodo static non è esposto su un'istanza; questo è parzialmente vero Ma questo è un argomento su evitare l'errore dello sviluppatore , non sulla correttezza logica.
Inoltre: una statica protetta è ancora disponibile pubblicamente all'interno della sua classe e tutte le classi che ne derivano. Non è disponibile come this.MyStaticMethod() , ma è ancora disponibile come MyStaticMethod() . Non stai completamente aggirando la sua disponibilità.

Ciò che dici non è sbagliato, ma non vedo argomenti che giustifichino questo ulteriore livello di astrazione.