Qual è l'alternativa a Singleton

Question

Abbiamo una classe che contiene le informazioni di configurazione per l'applicazione. Era un singleton. Dopo una revisione architettonica, ci è stato detto di rimuovere il singleton. Abbiamo visto alcuni vantaggi nel non utilizzare singleton nei test delle unità perché possiamo testare diverse configurazioni tutte in una volta.

Senza singleton, dobbiamo passare l'istanza ovunque nel nostro codice. È diventato così complicato che abbiamo scritto un involucro singleton. Ora stiamo trasferendo lo stesso codice a PHP e .NET, mi chiedo se ci sia un modello migliore che possiamo usare per l'oggetto di configurazione.

Answer 1

Lo Google Testing blog ha una serie di voci su come evitare Singleton (per creare codice verificabile). Forse questo può aiutare:

• Using dependency injection to avoid singletons
• Singletons are Pathological Liars
• Root Cause of Singletons
• Where have all the Singletons Gone?

L'ultimo articolo spiega in dettaglio come spostare la creazione di nuovi oggetti in una fabbrica, in modo da puoi evitare di usare singleton.Vale la pena leggere di sicuro.

In breve spostiamo tutti i nuovi operatori in fabbrica. Raggruppiamo tutti gli oggetti di durata simile in una singola fabbrica.

Answer 2

È una classe che contiene solo metodi e campi statici possibili? Non sono sicuro di quale sia esattamente la tua situazione, ma potrebbe valere la pena esaminarla.

Answer 3

Il modo migliore è utilizzare invece un modello di fabbrica. Quando si costruisce una nuova istanza della classe (in fabbrica) è possibile inserire i dati "globali" nell'oggetto di nuova costruzione, come riferimento a una singola istanza (che si memorizza nella classe factory) o copiando la pertinente dati nel nuovo oggetto.

Tutti i tuoi oggetti conterranno quindi i dati che erano abituati a vivere nel singleton. Non penso che ci sia molta differenza nel complesso, ma può rendere il tuo codice più facile da leggere.

Answer 4

Qui potrei affermare l'ovvio, ma esiste un motivo per cui non è possibile utilizzare un'infrastruttura per le dipendenze, ad esempio Spring o Guice? (Credo che Spring sia disponibile anche per .NET ora).

In questo modo, il framework può contenere una singola copia degli oggetti di configurazione ei bean (servizi, DAO, qualsiasi cosa) non devono preoccuparsi di cercarlo.

Questo è l'approccio che prendo di solito!

Answer 5

Forse non molto pulita, ma si potrebbe forse passare i bit di informazione che si desidera hanno cambiato il metodo che crea il Singleton - invece di usare

public static Singleton getInstance() { 
    if(singleton != null) 
     createSingleton(); 
     return singleton; 
    } 
} 

si potrebbe chiamare createSingleton(Information info) direttamente all'avvio dell'applicazione (e nei metodi setUp dei test unitari).

Answer 6

Se si utilizza Spring Framework, è possibile semplicemente creare un bean regolare. Per impostazione predefinita (o se si imposta in modo esplicito scope="singleton") viene creata solo un'istanza del bean e tale istanza viene restituita ogni volta che il bean viene utilizzato in una dipendenza o recuperato tramite getBean().

Si ottiene il vantaggio della singola istanza, senza l'accoppiamento del modello Singleton.

Answer 7

Dipende da quali strumenti/strutture ecc. Vengono utilizzati. Con gli strumenti di input/ioc di dipendenza si può spesso ottenere prestazioni/ottimizzazioni singleton facendo in modo che il contenitore di/ioc usi il comportamento di singleton per la classe richiesta (come un'interfaccia IConfigSettings) creando sempre un'istanza della classe. Questo potrebbe essere ancora sostituito per testare

In alternativa si potrebbe usare una fabbrica per creare la classe e restituire la stessa istanza ogni volta che si richiede - ma per il test potrebbe restituire un/versione deriso contuso

Answer 8

L'alternativa sta passando in quello di cui hai bisogno invece di chiedere un oggetto per le cose.

Answer 9

Verifica la possibilità di configurare la configurazione come interfaccia di richiamo. codice in modo sensibile la configurazione sarà:

MyReuseCode.Configure(IConfiguration) 

codice di sistema-init sarà:

Library.init(MyIConfigurationImpl) 

Answer 10

non si accumulano responsibilites ad un singolo oggetto di configurazione dal momento che sarà termina con una molto grande oggetto che è al tempo stesso difficile da capire e fragile.

Ad esempio se è necessario un altro parametro per una particolare classe, modificare l'oggetto Configuration, quindi ricompilare tutte le classi che lo utilizzano. Questo è un po 'problematico.

Provare a refactoring il codice per evitare un oggetto comune, globale e grande Configuration. Passare parametri solo necessari per le classi client:

class Server { 

    int port; 

    Server(Configuration config) { 
     this.port = config.getServerPort(); 
    } 

} 

dovrebbe essere riscritta a:

class Server { 

    public Server(int port) { 
     this.port = port; 
    } 
} 

un'iniezione quadro dipendenza aiuterà molto qui, ma non è stricly necessaria.

Answer 11

È possibile utilizzare un framework di iniezione delle dipendenze per alleviare il dolore del passaggio nell'oggetto di configurazione. Uno decente è ninject che ha il vantaggio di utilizzare il codice anziché xml.

Answer 12

È possibile eseguire lo stesso comportamento di singleton utilizzando metodi statici. Steve yegge lo spiega molto bene nel post this.

Answer 13

I singleton non sono malvagi ma il modello di progettazione è imperfetto. Ho una classe che voglio solo creare una singola istanza di esso durante il runtime ma voglio creare più istanze isolate durante i test unitari per garantire risultati deterministici.

DI utilizzando Spring, ecc. È un'opzione molto buona ma non l'unica opzione.