Perché una classe statica non dovrebbe avere uno stato interno?

Question

Perché una classe statica non dovrebbe avere uno stato interno?

#1 da (5 voti)

4

Mentre lavoravo a un progetto, ho deciso di creare una classe di database per gestire la mia connessione DB. Ho iniziato a cercare la pratica migliore per farlo, che di solito è una classe statica o una classe di pattern singleton. Le risposte che ho trovato, come ad esempio:

link

Quando usare un Singleton e quando utilizzare una classe statica

Favorire l'approccio singleton rispetto a quello statico, per ragioni per lo più comprensibili (rendere più sicuri i thread, utilizzare le funzionalità OOP, testare più facilmente ...), ma una ragione che non riesco a capire è che le classi statiche non dovrebbero avere alcun tipo di stato. Qualcuno potrebbe spiegargli la ragione?

object-oriented singleton static-access

posta Wisam Shaker 10.12.2016 - 20:24

fonte

1 risposta

Leggi altre domande sui tag object-oriented singleton static-access

Dove inserire le annotazioni JPA? Field, o getter? Blocchi ElseIf-Else ridondanti [duplicato]

score 5 · Answer 1

Why shouldn't a static class have an internal state?

Perché, nel contesto al quale ti stai collegando, non lo stato interno è la DEFINIZIONE di una classe statica.

Qui la classe statica non significa static class . Significa java.lang.Math . Questa è una classe finale piena di metodi statici.

Ora che il nostro vocabolario è chiaro ...

@Doval Why shouldn't it? – Aviv Cohn Apr 10 '14 at 14:02

Bene ...

@Prog Because you're just using global variables in disguise. All parts of your application that make any calls to the static class are now invisibly dependent on each other, and any parts of your application that are dependent on those parts are now indirectly dependent as well, and so on. Mutable state is already a bad idea if you can avoid it. Global mutable state is just a bad idea. – Doval Apr 10 '14 at 14:05

Quindi, perché

Favor the singleton approach over the static one

Perché Murphy era un ottimista. Dici che hai solo una risorsa DB ora, ma supponi che cambi?

Progettare l'idea che ci sia sempre e solo qualcosa di qualsiasi cosa è dimenticare perché risolviamo alcuni problemi con le tastiere, non con i saldatori.

Io preferisco l'approccio di istanza immutabile (non posso portarmi a dire singleton perché il pattern di Goell singleton è così così non ottimale) perché lo stato mutabile condiviso è il vero peccato.

Fammi un modo per ottenere un'istanza immutabile che punta alla risorsa DB con cui vuoi parlare e parlerò con essa. Che si tratti della tua prima o seconda risorsa DB non sono affari miei.

Questa è un'iniezione di dipendenza. Il conteggio del numero di risorse DB è ora un problema spinto nella costruzione. Da lì, se lo desideri, puoi inviarlo alla configurazione.

Ora ammetto di essere di parte. Non devi usare DI. Puoi usare singleton. Ecco un articolo ben considerato a confronto Singleton vs Dipendenza dell'iniezione .

Salterò in estate:

If a dependency is ambient, meaning that it is used by many classes and/or multiple layers, use Singleton.

Otherwise, inject it to the dependent classes using the Dependency Injection pattern.

Che amo perché mi consente semplicemente di dire questo: non scrivere codice che mette il tuo DB nel caso 1.