Cosa c'è di così brutto nei single? [chiuso]

Il pattern Singleton è un membro interamente versato della GoF s' il libro di modelli , ma ultimamente sembra piuttosto orfano da parte del mondo degli sviluppatori. Uso ancora parecchi singleton, soprattutto per le lezioni di fabbrica , e mentre devi stare un po 'attento ai problemi del multithreading (come qualsiasi classe in realtà), non riesco a capire perché siano così terribili.

Stack Overflow sembra soprattutto supporre che tutti siano d'accordo sul fatto che i Singleton siano cattivi. Perché?

Supportare le risposte con " fatti, riferimenti o competenze specifiche "

Parafrasato da Brian Button:

1. Sono generalmente utilizzati come istanza globale, perché è così male? Perché nascondi le dipendenze della tua applicazione nel tuo codice, invece di esporle attraverso le interfacce. Fare qualcosa di globale per evitare di passarlo in giro è un odore di codice .

2. Essi violano il principio della singola responsabilità : in virtù del fatto che controllano la propria creazione e il proprio ciclo di vita.

3. Essi causano intrinsecamente un accoppiamento stretto del codice . Ciò rende in molti casi falsificarli sotto test piuttosto difficili.

4. Portano lo stato in giro per tutta la durata dell'applicazione. Un altro colpo ai test poiché è possibile che si verifichi una situazione in cui è necessario ordinare i test, il che è un grande no per i test unitari. Perché? Perché ogni test unitario dovrebbe essere indipendente dall'altro.

I singoli risolvono un (e solo un) problema.

Contesa di risorse.

Se hai qualche risorsa che

( 1 ) può avere solo una singola istanza e

( 2 ) devi gestire quella singola istanza,

hai bisogno di un singleton .

Non ci sono molti esempi. Un file di registro è quello più grande. Non vuoi abbandonare solo un singolo file di registro. Vuoi svuotare, sincronizzare e chiuderlo correttamente. Questo è un esempio di una singola risorsa condivisa che deve essere gestita.

È raro che tu abbia bisogno di un singleton. Il motivo per cui sono cattivi è che si sentono come un globale e sono un membro pienamente pagato del libro GoF Design Patterns .

Quando pensi di aver bisogno di un globale, probabilmente stai commettendo un terribile errore di progettazione.

Alcuni snob di codifica li guardano come un globale glorificato. Allo stesso modo in cui molte persone odiano l' affermazione goto , ce ne sono altre che odiano l'idea di usare mai un globale . Ho visto diversi sviluppatori fare di tutto per evitare un globale perché hanno considerato di usarne uno come ammissione di fallimento. Strano ma vero.

In pratica il modello Singleton è solo una tecnica di programmazione che è una parte utile del tuo insieme di concetti. Di tanto in tanto potresti trovare la soluzione ideale e quindi usarla. Ma usarlo solo per vantarti di utilizzare un modello di progettazione è altrettanto stupido che rifiutarsi di usarlo perché è solo un globale .

Misko Hevery, di Google, ha alcuni articoli interessanti proprio su questo argomento ...

I singleton sono patologici bugiardi ha un esempio di test unitario che illustra come i singleton possono rendere difficile capire le catene di dipendenze e avviare o testare un'applicazione. È un esempio abbastanza estremo di abuso, ma il punto che afferma è ancora valido:

I singoli non sono altro che lo stato globale. Lo stato globale lo rende in modo che i tuoi oggetti possano segretamente impadronirsi di cose che non sono dichiarate nelle loro API e, di conseguenza, i Singleton trasformano le tue API in bugiardi patologici.

Dove sono finiti tutti i Singletons Gone sottolinea che l'iniezione di dipendenza ha reso facile ottenere istanze per i costruttori che li richiedono, il che allevia il bisogno sottostante alla base dei Singletons cattivi e globali denunciati nel primo articolo.

Penso che la confusione sia causata dal fatto che le persone non conoscono la vera applicazione del modello Singleton. Non posso sottolineare abbastanza. Singleton non è un modello per avvolgere i globi. Il modello Singleton deve essere utilizzato solo per garantire l' esistenza di una sola istanza di una determinata classe durante il runtime.

La gente pensa che Singleton sia malvagio perché lo sta usando per i globi. È a causa di questa confusione che Singleton è guardato in basso. Per favore, non confondere Singletons e globals. Se utilizzato per lo scopo a cui era destinato, otterrai benefici estremi dal modello Singleton.

Una cosa piuttosto negativa dei single è che non puoi estenderli molto facilmente. Fondamentalmente devi costruire una sorta di motivo decorativo o qualcosa del genere se vuoi cambiare il loro comportamento. Inoltre, se un giorno vuoi avere più modi di fare quella cosa, può essere piuttosto doloroso cambiare, a seconda di come disponi il tuo codice.

Una cosa da notare, se usi i singleton, prova a passarli a chiunque ne abbia bisogno piuttosto che farli accedere direttamente ... Altrimenti se scegli di avere più modi di fare ciò che singleton fa, sarà piuttosto difficile da cambiare poiché ogni classe incorpora una dipendenza se accede direttamente al singleton.

Quindi in poche parole:

public MyConstructor(Singleton singleton) {
    this.singleton = singleton;
}

piuttosto che:

public MyConstructor() {
    this.singleton = Singleton.getInstance();
}

Credo che questo tipo di schema si chiami iniezione di dipendenza ed è generalmente considerato una buona cosa.

Come ogni schema però ... Pensaci e considera se il suo uso in una determinata situazione è inappropriato o no ... Le regole sono fatte per essere infrante di solito, e gli schemi non dovrebbero essere applicati volenti o nolenti senza pensarci.

Il modello singleton non è un problema in sé. Il problema è che il modello viene spesso utilizzato dalle persone che sviluppano software con strumenti orientati agli oggetti senza avere una solida conoscenza dei concetti di OO. Quando i singleton vengono introdotti in questo contesto, tendono a crescere in classi ingestibili che contengono metodi di supporto per ogni piccolo uso.

Anche i singoli sono un problema dal punto di vista dei test. Tendono a rendere difficili i test unitari isolati da scrivere. L'inversione del controllo (IoC) e l' iniezione delle dipendenze sono schemi intesi a superare questo problema in modo orientato agli oggetti che si presta a test unitari.

In un ambiente di immondizia , i singleton possono rapidamente diventare un problema per quanto riguarda la gestione della memoria.

C'è anche lo scenario multi-thread in cui i singoli possono diventare un collo di bottiglia e un problema di sincronizzazione.

Un singleton viene implementato utilizzando un metodo statico. I metodi statici sono evitati dalle persone che eseguono i test unitari perché non possono essere derisi o sradicati. La maggior parte delle persone su questo sito sono grandi sostenitori dei test unitari. La convenzione generalmente accettata per evitarli sta usando l' inversione del modello di controllo .

Anche i singoli sono cattivi quando si tratta di raggruppamento . Perché allora, non hai più "esattamente un singleton" nella tua applicazione.

Considerare la seguente situazione: come sviluppatore, è necessario creare un'applicazione Web che acceda a un database. Per garantire che le chiamate al database simultanee non siano in conflitto tra loro, si crea un thread-save SingletonDao:

public class SingletonDao {
    // songleton's static variable and getInstance() method etc. omitted
    public void writeXYZ(...){
        synchronized(...){
            // some database writing operations...
        }
    }
}

Quindi sei sicuro che esiste un solo singleton nella tua applicazione e tutto il database passa attraverso questo e solo SingletonDao. Il tuo ambiente di produzione ora appare così:

Finora tutto bene.

Ora, considera di voler impostare più istanze della tua applicazione web in un cluster. Ora improvvisamente hai qualcosa del genere:

Sembra strano, ma ora hai molti singoli nella tua applicazione . Ed è esattamente ciò che un singleton non dovrebbe essere: avere molti oggetti. Ciò è particolarmente negativo se, come mostrato in questo esempio, si desidera effettuare chiamate sincronizzate a un database.

Ovviamente questo è un esempio di un cattivo utilizzo di un singleton. Ma il messaggio di questo esempio è: non puoi fare affidamento sul fatto che esiste esattamente un'istanza di un singleton nella tua applicazione, specialmente quando si tratta di clustering.

1. È facilmente (ab) utilizzato come variabile globale.
2. Le classi che dipendono dai singoli sono relativamente più difficili da testare unitamente.

Il monopolio è il diavolo e i singoli con stato non di sola lettura / mutevole sono il problema "reale" ...

Dopo aver letto i Singleton sono bugiardi patologici, come suggerito nella risposta di Jason, mi sono imbattuto in questo piccolo bocconcino che fornisce l'esempio meglio presentato di come i singleton vengono spesso utilizzati in modo improprio.

Global è male perché:

• un. Causa conflitto nello spazio dei nomi
• b. Espone lo stato in modo ingiustificato

Quando si tratta di Singletons

• un. Il modo esplicito OO di chiamarli, previene i conflitti, quindi indica a. non è un problema
• b. I singoli senza stato (come le fabbriche) non sono un problema. I singoli con stato possono di nuovo rientrare in due categorie, quelli che sono immutabili o scrivono una volta e ne leggono molti (file di configurazione / proprietà). Questi non sono male. Singleton mutabili, che sono tipi di titolari di riferimento sono quelli di cui stai parlando.

Nell'ultima affermazione si riferisce al concetto del blog di "i single sono bugiardi".

Come si applica a Monopoli?

Per iniziare una partita di monopolio, prima di tutto:

• stabiliamo prima le regole in modo che tutti siano sulla stessa pagina
• a tutti viene dato un inizio uguale all'inizio del gioco
• viene presentato un solo insieme di regole per evitare confusione
• le regole non possono cambiare durante il gioco

Ora, per chiunque non abbia veramente giocato al monopolio, questi standard sono nella migliore delle ipotesi ideali. Una sconfitta nel monopolio è difficile da inghiottire perché, il monopolio riguarda i soldi, se perdi devi guardare scrupolosamente il resto dei giocatori che finiscono il gioco, e le perdite sono di solito rapide e schiaccianti. Quindi, le regole di solito vengono distorte a un certo punto per servire l'interesse personale di alcuni giocatori a spese degli altri.

Quindi stai giocando a monopolio con gli amici Bob, Joe ed Ed. Stai rapidamente costruendo il tuo impero e consumando quote di mercato a un ritmo esponenziale. I tuoi avversari si stanno indebolendo e inizi a sentire l'odore del sangue (in senso figurato). Il tuo amico Bob ha investito tutti i suoi soldi nel bloccare il maggior numero possibile di proprietà di basso valore, ma il suo non sta ricevendo un elevato ritorno sugli investimenti come si aspettava. Bob, come un colpo di sfortuna, atterra sul tuo Boardwalk e viene eliminato dal gioco.

Ora il gioco passa dal lancio dei dadi amichevole agli affari seri. A Bob è stato fatto l'esempio del fallimento e Joe ed Ed non vogliono finire come "quel ragazzo". Quindi, essendo il protagonista, all'improvviso diventi nemico. Joe ed Ed iniziano a praticare scambi sotto il tavolo, iniezioni di denaro dietro la schiena, cambio di casa sottovalutato e in genere qualsiasi cosa per indebolirti come giocatore fino a quando uno di loro non sale in cima.

Quindi, invece di vincere uno di loro, il processo ricomincia da capo. All'improvviso, un insieme finito di regole diventa un bersaglio mobile e il gioco degenera nel tipo di interazioni sociali che costituirebbero la base di ogni programma televisivo di alto livello dopo Survivor. Perché, perché le regole stanno cambiando e non c'è consenso su come / perché / cosa dovrebbero rappresentare e, cosa più importante, non c'è nessuno che prenda le decisioni. Ogni giocatore nel gioco, a quel punto, sta facendo le proprie regole e il caos ne consegue fino a quando due dei giocatori non sono troppo stanchi per mantenere la sciarada e rinunciare lentamente.

Quindi, se un libro delle regole per un gioco rappresentasse accuratamente un singleton, il libro delle regole del monopolio sarebbe un esempio di abuso.

Come si applica alla programmazione?

A parte tutti gli ovvi problemi di sicurezza dei thread e di sincronizzazione che presentano singlet mutabili ... Se si dispone di un set di dati, che è in grado di essere letto / manipolato da più origini diverse contemporaneamente ed esiste durante la vita dell'esecuzione dell'applicazione, è probabilmente un buon momento per fare un passo indietro e chiedere "sto usando il giusto tipo di struttura di dati qui".

Personalmente, ho visto un programmatore abusare di un singleton utilizzandolo come una sorta di archivio contorto tra thread incrociati all'interno di un'applicazione. Avendo lavorato direttamente sul codice, posso attestare che è stato lento (a causa di tutti i blocchi di thread necessari per renderlo thread-safe) e un incubo su cui lavorare (a causa della natura imprevedibile / intermittente dei bug di sincronizzazione), e quasi impossibile testare in condizioni di "produzione". Certo, un sistema avrebbe potuto essere sviluppato utilizzando polling / signaling per superare alcuni dei problemi di prestazioni, ma ciò non risolverebbe i problemi con i test e, perché preoccuparsi quando un database "reale" può già realizzare la stessa funzionalità in un modo molto più robusto / modo scalabile.

Un Singleton è un'opzione solo se hai bisogno di ciò che fornisce un singleton. Un'istanza di sola lettura in scrittura di un oggetto. La stessa regola dovrebbe arrivare anche alle proprietà / ai membri dell'oggetto.

Singleton non riguarda la singola istanza!

A differenza di altre risposte, non voglio parlare di ciò che è sbagliato in Singletons, ma di mostrarti quanto sono potenti e fantastici se usati correttamente!

• Problema : Singleton può rappresentare una sfida nell'ambiente multi-thread
  Soluzione : Utilizzare un processo bootstrap a thread singolo per inizializzare tutte le dipendenze del proprio singleton.
• Problema : è difficile deridere i singoli.
  Soluzione : utilizzare il metodo Modello di fabbrica per deridere

Puoi mappare MyModelsulla TestMyModelclasse che lo eredita, ovunque MyModelti verrà iniettato riceverai TestMyModelistruzioni. - Problema : i singoli possono causare perdite di memoria poiché non vengono mai eliminati.
Soluzione : eliminali! Implementa un callback nella tua app per smaltire correttamente i singoli, dovresti rimuovere tutti i dati ad essi collegati e infine: rimuoverli dalla Factory.

Come ho affermato nel titolo, singleton non riguarda la singola istanza.

• Singletons migliora la leggibilità : puoi guardare la tua classe e vedere quale singleton ha iniettato per capire quali sono le sue dipendenze.
• Singletons migliora la manutenzione : una volta rimossa una dipendenza da una classe, hai appena eliminato l'iniezione singleton, non è necessario andare a modificare un grande link di altre classi che hanno appena spostato la tua dipendenza (questo è un codice puzzolente per me @Jim Burger )
• Singletons migliora la memoria e le prestazioni : quando succede qualcosa nella tua applicazione, e ci vuole una lunga catena di callback per consegnare, stai sprecando memoria e prestazioni, usando Singleton stai tagliando l'uomo intermedio e migliorando le tue prestazioni e l'utilizzo della memoria ( evitando allocazioni di variabili locali non necessarie).

La mia risposta su come i Singleton sono cattivi è sempre "sono difficili da fare bene". Molti dei componenti fondamentali dei linguaggi sono singoli (classi, funzioni, spazi dei nomi e persino operatori), così come i componenti in altri aspetti dell'informatica (localhost, route predefinita, filesystem virtuale, ecc.), E non è un caso. Mentre di tanto in tanto causano problemi e frustrazione, possono anche far funzionare molte cose molto MOLTO meglio.

I due maggiori errori che vedo sono: trattarlo come un globale e non riuscire a definire la chiusura di Singleton.

Tutti parlano di Singleton come globali, perché in pratica lo sono. Tuttavia, gran parte (purtroppo, non tutta) della cattiveria in un globale non deriva intrinsecamente dall'essere globale, ma dal modo in cui la usi. Lo stesso vale per Singletons. In realtà più come "singola istanza" in realtà non deve significare "accessibile a livello globale". È più un sottoprodotto naturale e, dato tutto il male che sappiamo che ne deriva, non dovremmo avere tanta fretta di sfruttare l'accessibilità globale. Quando i programmatori vedono un Singleton sembrano accedervi sempre direttamente attraverso il suo metodo di istanza. Invece, dovresti accedervi come faresti con qualsiasi altro oggetto. La maggior parte del codice non dovrebbe nemmeno essere consapevole che si tratta di un Singleton (accoppiamento libero, giusto?). Se solo un po 'di codice accede all'oggetto come se fosse un globale, molti danni vengono annullati.

Anche il contesto Singleton è davvero importante. La caratteristica distintiva di un Singleton è che esiste "solo uno", ma la verità è che è "solo uno" all'interno di una sorta di contesto / spazio dei nomi. Di solito sono uno di: uno per thread, processo, indirizzo IP o cluster, ma possono anche essere uno per processore, macchina, spazio dei nomi di lingua / caricatore di classe / qualunque cosa, sottorete, Internet, ecc.

L'altro, meno comune, errore è ignorare lo stile di vita Singleton. Solo perché ce n'è solo uno non significa che Singleton sia un po 'onnipotente "lo è sempre stato e lo sarà sempre", né è generalmente desiderabile (gli oggetti senza un inizio e una fine violano tutti i tipi di ipotesi utili nel codice e dovrebbero essere impiegati solo nelle circostanze più disperate.

Se si evitano questi errori, Singletons può ancora essere un PITA, ma è pronto a vedere che molti dei problemi peggiori sono significativamente mitigati. Immagina un Java Singleton, che viene esplicitamente definito come una volta per classloader (il che significa che ha bisogno di una politica di sicurezza dei thread), con metodi di creazione e distruzione definiti e un ciclo di vita che detta quando e come vengono invocati, e il cui metodo "istanza" ha protezione del pacchetto in modo che sia generalmente accessibile tramite altri oggetti non globali. Ancora una potenziale fonte di problemi, ma sicuramente molto meno problemi.

Purtroppo, piuttosto che insegnare buoni esempi di come fare Singletons. Insegniamo cattivi esempi, lasciamo che i programmatori scappino usandoli per un po 'e poi diciamo loro che sono un cattivo modello di progettazione.

Vedi Wikipedia Singleton_pattern

È anche considerato un anti-modello da alcune persone, che ritengono che sia eccessivamente usato, introducendo limitazioni inutili in situazioni in cui non è richiesta una sola istanza di una classe. [1] [2] [3] [4]

Riferimenti (solo riferimenti pertinenti dall'articolo)

1. ^ Alex Miller. Modelli che odio n. 1: Singleton , luglio 2007
2. ^ Scott Densmore. Perché i single sono cattivi , maggio 2004
3. ^ Steve Yegge. Singletons considerato stupido , settembre 2004
4. ^ JB Rainsberger, IBM. Usa i tuoi singoli saggiamente , luglio 2001

Non è che gli stessi singoli siano cattivi, ma lo è il modello di progettazione GoF. L'unico vero argomento valido è che il modello di progettazione GoF non si presta per quanto riguarda i test, soprattutto se i test vengono eseguiti in parallelo.

L'uso di una singola istanza di una classe è un costrutto valido purché si applichino i seguenti mezzi nel codice:

1. Assicurarsi che la classe che verrà utilizzata come singleton implementa un'interfaccia. Ciò consente di realizzare stub o mock usando la stessa interfaccia

2. Assicurarsi che Singleton sia thread-safe. Questo è un dato.

3. Il singleton dovrebbe essere semplice in natura e non eccessivamente complicato.

4. Durante il runtime dell'applicazione, in cui è necessario passare i singleton a un determinato oggetto, utilizzare una factory di classe che costruisce quell'oggetto e fare in modo che la factory di classe passi l'istanza singleton alla classe che ne ha bisogno.

5. Durante il test e per garantire un comportamento deterministico, creare la classe singleton come istanza separata come la classe effettiva stessa o uno stub / mock che implementa il suo comportamento e passarlo così com'è alla classe che lo richiede. Non usare il fattore di classe che crea quell'oggetto sotto test che necessita del singleton durante il test poiché passerà la singola istanza globale di esso, il che vanifica lo scopo.

Abbiamo utilizzato Singletons nelle nostre soluzioni con un grande successo che è testabile garantendo un comportamento deterministico in flussi di test paralleli.

Vorrei affrontare i 4 punti nella risposta accettata, spero che qualcuno possa spiegare perché mi sbaglio.

1. Perché nascondere le dipendenze nel tuo codice è male? Esistono già dozzine di dipendenze nascoste (chiamate di runtime C, chiamate API del sistema operativo, chiamate di funzione globali) e le dipendenze singleton sono facili da trovare (cercare ad esempio ()).

   "Creare qualcosa di globale per evitare di passarlo in giro è un odore di codice." Perché non passare qualcosa in giro per evitare di renderlo un singleton un odore di codice?

   Se stai passando un oggetto attraverso 10 funzioni in uno stack di chiamate solo per evitare un singleton, è fantastico?

2. Principio unico di responsabilità: penso che questo sia un po 'vago e dipende dalla tua definizione di responsabilità. Una domanda rilevante sarebbe: perché l'aggiunta di questa "responsabilità" specifica a una questione di classe?

3. Perché passare un oggetto a una classe lo rende più strettamente accoppiato rispetto all'utilizzo di quell'oggetto come singleton all'interno della classe?

4. Perché cambia quanto dura lo stato? I singleton possono essere creati o distrutti manualmente, quindi il controllo è ancora lì e puoi rendere la durata uguale a quella di un oggetto non singleton.

Per quanto riguarda i test unitari:

• non tutte le classi devono essere testate in unità
• non tutte le classi che devono essere testate in unità devono cambiare l'implementazione del singleton
• se lo fanno necessario unità testato e hanno bisogno di cambiare l'implementazione, è facile cambiare una classe di utilizzare un Singleton ad avere il Singleton passata ad esso tramite l'iniezione di dipendenza.

Vince Huston ha questi criteri, che mi sembrano ragionevoli:

Singleton dovrebbe essere considerato solo se tutti e tre i seguenti criteri sono soddisfatti:

• La proprietà della singola istanza non può essere ragionevolmente assegnata
• L'inizializzazione lenta è desiderabile
• L'accesso globale non è altrimenti previsto

Se la proprietà della singola istanza, quando e come avviene l'inizializzazione e l'accesso globale non sono problemi, Singleton non è sufficientemente interessante.

I single sono cattivi da un punto di vista purista.

Da un punto di vista pratico, un singleton è un compromesso tra tempo di sviluppo e complessità .

Se sai che la tua applicazione non cambierà molto, sono abbastanza OK. Sappi solo che potresti dover riformattare le cose se le tue esigenze cambiano in modo imprevisto (il che è abbastanza OK nella maggior parte dei casi).

I singleton a volte complicano anche i test unitari .

Non c'è nulla di intrinsecamente sbagliato nello schema, supponendo che sia usato per qualche aspetto del tuo modello che è veramente singolo.

Credo che il contraccolpo sia dovuto al suo uso eccessivo che, a sua volta, è dovuto al fatto che è il modello più semplice da comprendere e implementare.

Non commenterò l'argomento buono / cattivo, ma non li uso da quando è arrivata la primavera . L'uso dell'iniezione di dipendenza ha praticamente rimosso i miei requisiti per singleton, tecnici e fabbriche. Trovo questo un ambiente molto più produttivo e pulito, almeno per il tipo di lavoro che faccio (applicazioni web basate su Java).

Singleton è un modello e può essere utilizzato o abusato come qualsiasi altro strumento.

La parte negativa di un singleton è generalmente l'utente (o dovrei dire l'uso inappropriato di un singleton per cose che non è progettato per fare). L'autore del reato più grande sta usando un singleton come falsa variabile globale.

Quando si scrive codice utilizzando singleton, ad esempio un logger o una connessione al database, e successivamente si scopre che è necessario più di un registro o più di un database, si è nei guai.

I single rendono molto difficile il passaggio da oggetti normali.

Inoltre, è troppo facile scrivere un singleton non thread-safe.

Invece di usare i singoli, è necessario passare tutti gli oggetti di utilità necessari da una funzione all'altra. Ciò può essere semplificato se li avvolgi tutti in un oggetto helper, in questo modo:

void some_class::some_function(parameters, service_provider& srv)
{
    srv.get<error_logger>().log("Hi there!");
    this->another_function(some_other_parameters, srv);
}

Il problema con i singoli è il problema di una maggiore portata e quindi dell'accoppiamento . Non si può negare che ci siano alcune situazioni in cui è necessario accedere a una singola istanza e ciò può essere realizzato in altri modi.

Ora preferisco progettare attorno a un contenitore di inversione di controllo (IoC) e consentire al ciclo di vita di essere controllato dal contenitore. Questo ti dà il vantaggio delle classi che dipendono dall'istanza di non essere a conoscenza del fatto che esiste una singola istanza. La durata del singleton può essere modificata in futuro. Una volta che un tale esempio che ho incontrato di recente è stato un facile adattamento da single thread a multi-thread.

FWIW, se si tratta di un PIA quando si tenta di testarlo, allora andrà in PIA quando si tenta di eseguire il debug, correggere un bug o migliorarlo.

Articolo recente su questo argomento di Chris Reath a Coding Without Comments .

Nota: la codifica senza commenti non è più valida. Tuttavia, l'articolo a cui è stato collegato è stato clonato da un altro utente.

http://geekswithblogs.net/AngelEyes/archive/2013/09/08/singleton-i-love-you-but-youre-bringing-me-down-re-uploaded.aspx

I single non sono male. È negativo solo quando crei qualcosa di unico a livello globale che non è unico a livello globale.

Tuttavia, ci sono "servizi di ambito applicativo" (pensate a un sistema di messaggistica che fa interagire i componenti) - questo CHIAMA per un singleton, una "MessageQueue" - classe che ha un metodo "SendMessage (...)".

È quindi possibile effettuare le seguenti operazioni da ogni parte del luogo:

MessageQueue.Current.SendMessage (new MailArrivedMessage (...));

E, naturalmente, fai:

MessageQueue.Current.RegisterReceiver (questo);

nelle classi che implementano IMessageReceiver.

Troppe persone mettono oggetti che non sono thread-safe in un modello singleton. Ho visto esempi di un DataContext ( LINQ to SQL ) fatto in un modello singleton, nonostante il DataContext non sia thread-safe ed è puramente un oggetto unit-of-work.

Ecco un'altra cosa sui singoli che nessuno ha ancora detto.

Nella maggior parte dei casi "singletonity" è un dettaglio dell'implementazione per alcune classi piuttosto che caratteristica della sua interfaccia. L'inversione del contenitore di controllo può nascondere questa caratteristica agli utenti della classe; devi solo contrassegnare la tua classe come singleton (con @Singletonannotazioni in Java per esempio) e il gioco è fatto; IoCC farà il resto. Non è necessario fornire l'accesso globale all'istanza singleton perché l'accesso è già gestito da IoCC. Quindi non c'è nulla di sbagliato nei Singleton IoC.

I Singleton GoF al contrario degli IoC Singleton dovrebbero esporre "singletonity" nell'interfaccia attraverso il metodo getInstance (), e in modo che soffrano di tutto quanto detto sopra.

I single non sono cattivi, se lo usi correttamente e minimamente . Ci sono molti altri buoni modelli di design che a un certo punto sostituiscono le esigenze di singleton (e danno anche i migliori risultati). Ma alcuni programmatori non sono consapevoli di quei buoni schemi e usano il singleton per tutti i casi che rendono il singleton cattivo per loro.

In primo luogo, una classe e i suoi collaboratori devono innanzitutto svolgere lo scopo previsto anziché concentrarsi sulle persone a carico. La gestione del ciclo di vita (quando le istanze vengono create e quando escono dall'ambito di applicazione) non dovrebbe far parte della responsabilità delle classi. La migliore pratica accettata per questo è creare o configurare un nuovo componente per gestire le dipendenze usando l'iniezione delle dipendenze.

Spesso il software diventa più complicato, ha senso avere più istanze indipendenti della classe Singleton con stato diverso. Commettere codice per prendere semplicemente il singleton è sbagliato in questi casi. L'uso Singleton.getInstance()potrebbe essere ok per piccoli sistemi semplici ma non funziona / scala quando si potrebbe aver bisogno di un'istanza diversa della stessa classe.

Nessuna classe dovrebbe essere considerata come un singleton, ma piuttosto dovrebbe essere un'applicazione del suo utilizzo o di come viene utilizzata per configurare le persone a carico. Per un modo rapido e sgradevole questo non ha importanza - solo la codifica dura dice che i percorsi dei file non contano ma per applicazioni più grandi tali dipendenze devono essere fattorizzate e gestite in modo più appropriato usando DI.

I problemi che singleton causano nei test è un sintomo del loro caso / ambiente di utilizzo singolo codificato. La suite di test e i numerosi test sono singoli e separano qualcosa che non è compatibile con la codifica hardware di un singleton.

Poiché sono sostanzialmente variabili globali orientate agli oggetti, di solito puoi progettare le tue classi in modo tale da non averne bisogno.