come refactoring molti singletons

I singleton sono considerati "malvagi" da molti, e mentre un modello singleton ha i suoi usi sono pochi e lontani tra loro ... Ho lavorato con diverse codebase di grandi dimensioni e sono praticamente riuscito sempre a spostarli dai singleton.

Il modo più semplice per eliminare i singleton è:

1. Introduci un'interfaccia in cima al tuo singleton : questo ti consente di separare il contratto dall'implementazione e riduce l'accoppiamento che hai all'attuale implementazione
2. Fornisci un setter sul tuo singleton in modo da poter impostare l'istanza singleton da un unittest : questo ti consente di "scambiare" l'istanza singleton in un unittest.
3. Crea le unittests sulla classe che vuoi cambiare : usando una simulazione dell'interfaccia presentata in 1 e il setter introdotto in 2 puoi ora scrivere le unittests sulla classe.
4. Inietti il singleton invece di farlo staticamente : nella classe che dipende dal singleton, hai un modo per iniettare quel singleton (tramite l'interfaccia creata in 1). È possibile utilizzare l'iniezione del costruttore, i setter basati sui metodi .... Qualunque cosa funzioni per voi. Questa è la prima volta che tocchi la classe che stai rifacendo! I test introdotti in 3 ti aiuteranno a refactoring senza rompere nulla

Puoi evitare il passaggio 2 se vuoi farlo all-in, ma questo approccio è il più puro, nel senso che eviti di cambiare le classi che non hanno test per verificare che non si rompa nulla. Personalmente, trovo che questo sia un po 'eccessivo, ma YMMV. La premessa di base è che ti sposti verso una classe che ha inserito le dipendenze invece di essere scaricata staticamente.

Inoltre, anche se hai usi legittimi per un singleton dovresti ANALIZZARLI. I single servono a garantire che esista solo una singola istanza di una determinata classe. Lo schema classico con una funzione statica accessibile a livello globale consente di ottenere questo risultato, ma sfortunatamente ci allontana dall'iniezione di quell'istanza a causa del codice di esempio errato che galleggia sul web. Ci sono un sacco di framework che possono gestire l'iniezione delle dipendenze per te e molti di loro avranno un modo per configurare un oggetto in modo che la stessa istanza venga riutilizzata in tutta l'applicazione, rendendolo effettivamente un singleton.

La paura dei singleton è molto esagerata. Se hai bisogno di affidabilità, esattamente uno dei tanti grandi costrutti, non c'è niente di sbagliato nell'averli. (Se desideri invece scrivere moduli statici e il linguaggio non ti consente, potrebbe essere un problema con la lingua, non con il tuo programma.)

Un argomento comune contro i singleton è che sono difficili da deridere per i test unitari. Ma ciò si applica solo se si codifica la propria classe nel codice. Il modello singleton si preoccupa veramente di assicurarsi che esista solo una istanza di una classe specifica . Nessuno ti impedisce di avere diverse implementazioni di un'interfaccia di servizio, ciascuna di cui è un singleton e di scambiarle / inserirle / caricarle dinamicamente come necessario per scopi aziendali e di test.