Le classi statiche con metodi statici sono considerate SOLIDE?

SOLID include il principio di sostituzione di Liskov che ha l'idea che "gli oggetti in un programma dovrebbero essere sostituibili con istanze dei loro sottotipi senza alterare la correttezza di quel programma".

Poiché le classi statiche con metodi statici (un po 'come la Mathclasse) non hanno affatto istanze, il mio sistema è considerato SOLID se ho classi statiche con metodi statici?

language-agnostic solid static-access

— Pacerier
fonte

Penso che questa domanda sia fantastica. Vediamo cosa ha da offrire la community.

— Saeed Neamati,

Una classe di matematica non include lo stato. Quindi non si passa davvero in giro oggetti di questo tipo. Quindi non sono sicuro di quanto sia rilevante.

— Martin York,

Non penso che si possa davvero dire che le classi statiche siano SOLIDI pure (molto per alcune delle stesse ragioni già menzionate), tuttavia le considererei un ottimo sostenitore e strumento del principio DRY.

— Dreza,

Come mai? Dalla mia esperienza, l'uso eccessivo di classi statiche si traduce principalmente in persone che si ripetono continuamente con metà del codice manipolando permanentemente un oggetto dio statico globale.

— back2dos,

Immagino che sto pensando di più in termini di classi di utilità per fornire un codice comune. Sono d'accordo che sono facili e spesso usati male, ma penso ancora che possano fornire mezzi utili per raggruppare codice comune in cui lo stato non è un problema

— dreza

Risposte:

LSP si applica al passaggio di un'istanza di una classe in un metodo, facendo in modo che il metodo faccia qualcosa con quell'istanza e produca spesso una sorta di risultato. Questo non ha importanza per le classi statiche poiché in C # non è possibile creare un'istanza di una classe statica.

Ancora più importante, le classi statiche sono sigillate e quindi non possono essere ereditate. Questo rende la tua domanda discutibile fino a quando C # va.

Si potrebbe dire che le classi statiche sono sempre conformi a LSP poiché non è mai possibile produrre una sottoclasse che viola tale principio. Si potrebbe anche dire che le classi statiche non sono mai conformi a LSP per lo stesso motivo.

In Java, le classi statiche sono leggermente diverse. Non è possibile contrassegnare una classe di livello superiore come "statica", quindi se si desidera creare una classe di utilità simile alle classi statiche di C #, è necessario dichiararla come finale nasconderne il costruttore. Una volta che lo fai, tuttavia, si comportano in modo simile a C #: non puoi istanziarli o sottoclassarli. Puoi dichiarare una classe interna come static, ma ciò non significa la stessa cosa che fa in C #: indica semplicemente una classe nidificata di primo livello .

VB.NET si comporta esattamente allo stesso modo di C # in questo caso, per quanto ne so.

Non hai detto se sei interessato agli altri principi, ma li includerò comunque per completezza.

S ingle principio di responsabilità : una classe statica seguire facilmente questo principio.
O penna / principio chiuso : poiché le classi statiche sono sigillate, non possono mai seguire questo principio.
L iskov principio di sostituzione : come sopra.
Ho principio nterface segregazione : non si applica ad una singola classe, ma la scissione una classe statica di grandi dimensioni in quelle più piccole, più specializzati potrebbe essere un passo verso seguendo questo principio.
D principio ependency inversione : classi statiche non possono implementare interfacce, quindi ogni classe usando dipenderà sempre qualsiasi attuazione esiste al momento. Le classi statiche violano quindi questo principio.

Poiché le classi statiche non soddisfano tutti e 5 i criteri, non sono SOLID.

— Adam Lear
fonte

dato che per essere SOLIDI significa che dobbiamo soddisfare tutti e 5 i criteri, ciò non significa che non siano SOLIDI?

— Pacerier,

@Pacerier Sì, ma non si dovrebbe cercare di dare una calotta a SOLID in ogni momento se non è necessario; dipende dal contesto della classe. Se è una classe di utilità o qualcosa del genere, va bene IMO non essere "SOLID", ma se si tratta di una vera classe di dominio che ha un utilizzo specifico del dominio ...

— Wayne Molina,

Non classificherei una classe come orientata agli oggetti e quindi direi che non può (e non dovrebbe provare a) incontrare i principi del design orientato agli oggetti.

Queste classi sono semplicemente una soluzione all'incapacità di fornire codice al di fuori di una classe in linguaggi come Java e C #. Se potessero essere, dovrebbero essere definiti come funzioni autonome poiché non ottengono alcun vantaggio dall'orientamento agli oggetti.

— Gyan aka Gary Buyn
fonte

Non sarei d'accordo con l'inserimento di funzioni autonome al di fuori della classe. La semplice capacità di raggruppare le funzioni correlate (statiche o meno) sotto un nome comune è utile per la leggibilità. Le funzioni matematiche si adattano perfettamente al conto.

— jojo,

@jojo concordato. I linguaggi che supportano funzioni definite al di fuori delle classi supportano anche il raggruppamento logico di queste funzioni, ad esempio spazi dei nomi in C ++.

— Gyan aka Gary Buyn,

Vale la pena ricordare, dal momento che non è stato specificato alcun linguaggio, che in C ++ è possibile passare classi attorno alle quali sono presenti solo membri statici e accedere a tali membri tramite modello, quindi è possibile sostituire una classe con solo membri statici e, probabilmente, i metodi chiamato forma è "interfaccia".

— DeadMG
fonte

vb.net / c # / java

— Pacerier,