Quali sono gli usi validi delle classi statiche?

what if; what if; what if?

YAGNI

Scherzi a parte. Se qualcuno vuole utilizzare diverse implementazioni di File o Math o Console , allora può passare attraverso il dolore di astrarre quella via. Hai visto / usato Java?!? Le librerie standard Java sono un ottimo esempio di ciò che accade quando si astraggono le cose per motivi di astrazione. davvero devo passare attraverso 3 passaggi per creare il mio oggetto calendario ?

Tutto ciò che ho detto, non mi siederò qui e difendere strongmente le classi statiche. Lo stato statico è solidamente malvagio (anche se lo uso ancora occasionalmente per raggruppare / memorizzare le cose). Le funzioni statiche possono essere malvagie a causa di problemi di concorrenza e testabilità.

Ma le funzioni statiche pure non sono così terribili. Ci sono elementi elementari che non hanno senso astrarre perché non c'è un'alternativa sana per l'operazione. Ci sono implementazioni di una strategia che può essere statica perché sono già astratte tramite il delegato / funtore. E a volte a queste funzioni non è associata una classe di istanza, quindi le classi statiche vanno bene per organizzarle.

Inoltre, i metodi di estensione sono un uso pratico , anche se non sono classi filosoficamente statiche.

In una parola Semplicità.

Quando si disaccoppia troppo, si ottiene il ciao mondo dall'inferno.

void main(String[] args) {
    TextOutputFactory outputFactory = new TextOutputFactory();
    OutputStream stream = outputFactory.CreateStdOutputStream();

    Encoding encoding = new EncodingFactory.CreateUtf8Encoding();
    stream.Encoding = encoding;

    SystemConstant constant = new SystemConstant();
    stream.LineEnding = constant.PlatformLineEnding;

    stream.FlushOnEachLine = true;

    String greeting = new FixedSizeInMemoryString(); // We may have to switch to a file based string later!"
    greeting.SetContent("Hello world");
    greeting.Initialize();

    stream.SendContent(greeting);
    stream.EndCurrentLine();

    ProcessCompletion completion = new ProcessCompletion();
    completion.Status = constant.SuccessStatus;
    completion.ExitProgram();
}

Ma hey, almeno non c'è una configurazione XML, che è un bel tocco.

Le classi statiche consentono di ottimizzare per il caso rapido e comune. La maggior parte dei punti che hai menzionato possono essere risolti molto facilmente introducendo la tua astrazione su di loro, o usando cose come Console.Out.

Il caso dei metodi statici: Questo:

var c = Math.Max(a, Int32.Parse(b));

è molto più semplice e chiaro e più leggibile di questo:

IMathLibrary math = new DefaultMathLibrary();
IIntegerParser integerParser = new DefaultIntegerParser();
var c = math.Max(a, integerParser.Parse(b));

Ora aggiungi l'iniezione di dipendenza per nascondere le istanze esplicite, e vedi l'one-liner crescere in decine o centinaia di linee - tutto per supportare lo scenario improbabile che inventerai il tuo Max -implementazione che è significativamente più veloce di quello nel framework e devi essere in grado di passare in modo trasparente tra le alternative Max -implementazioni.

Il design delle API è un compromesso tra semplicità e flessibilità. Puoi sempre introdurre ulteriori livelli di riferimento indiretto ( ad infinitum ), ma devi valutare la convenienza del caso comune a vantaggio dei livelli aggiuntivi.

Ad esempio, è sempre possibile scrivere il proprio wrapper di istanza attorno all'API del file system se è necessario essere in grado di passare in modo trasparente tra i provider di archiviazione. Ma senza i metodi statici più semplici, tutti sarebbero costretti a creare un'istanza ogni volta che dovevano fare una cosa semplice come salvare un file. Sarebbe davvero un cattivo compromesso progettuale ottimizzare per un caso limite estremamente raro e rendere tutto più complicato per il caso comune. Lo stesso vale per Console : puoi creare facilmente il tuo wrapper se devi astrarre o prendere in giro la console, ma molto spesso usi la console per soluzioni rapide o per il debug, quindi vuoi semplicemente il modo più semplice per produrre del testo.

Inoltre, mentre "un'interfaccia comune con più implementazioni" è interessante, non c'è necessariamente un'astrazione "giusta" che unisca tutti i fornitori di storage che desideri. Potresti voler passare da un file all'altro all'archiviazione isolata, ma qualcun altro potrebbe voler passare da file, database e cookie per l'archiviazione. L'interfaccia comune sembrerebbe diversa, ed è impossibile prevedere tutte le possibili astrazioni che gli utenti potrebbero desiderare. È molto più flessibile fornire metodi statici come "primitive" e quindi consentire agli utenti di creare le proprie astrazioni e wrapper.

Il tuo esempio di Math è ancora più dubbio. Se si desidera passare a matematica di precisione arbitraria, è presumibile che siano necessari nuovi tipi numerici. Questo sarebbe un cambiamento fondamentale di tutto il tuo programma, e dover cambiare Math.Max() in ArbitraryPrecisionMath.Max() è certamente l'ultima delle tue preoccupazioni.

Detto questo, sono d'accordo che le classi statiche stateful sono nella maggior parte dei casi cattive.

In generale gli unici posti in cui userò le classi statiche sono quelli in cui la classe ospita funzioni pure che non attraversano i confini del sistema. Mi rendo conto che quest'ultimo è ridondante in quanto qualsiasi cosa che attraversa un confine è probabile per intento non puro. Vengo a questa conclusione sia da una sfiducia dello stato globale che da una prospettiva di facile analisi. Anche dove c'è una ragionevole aspettativa che ci sarà una singola implementazione per una classe che attraversa un confine di sistema (rete, file system, dispositivo I / O), scelgo di usare istanze piuttosto che classi statiche perché la possibilità di fornire una simulazione / L'implementazione falsa nei test unitari è fondamentale nello sviluppo di test rapidi delle unità senza alcun accoppiamento con i dispositivi reali. Nei casi in cui il metodo è una funzione pura senza alcun accoppiamento con un sistema / dispositivo esterno, ritengo che una classe statica possa essere appropriata, ma solo se non ostacola la testabilità. Trovo che i casi d'uso siano relativamente rari al di fuori delle classi quadro esistenti. Inoltre, ci possono essere casi in cui non hai scelta, ad esempio i metodi di estensione in C #.