In base al libro dei modelli GOF Design, è necessario utilizzare il modello Singleton quando:
there must be exactly one instance of a class, and it must be accessible to clients from a well-known access point
when the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code
qualcuno potrebbe chiarire il secondo punto?
Questa è una citazione dal libro Go4, ed è il secondo di due punti sotto la sezione Applicabilità ("Usa lo schema Singleton quando ...")
Questo punto non è proprio specifico di Singleton; significa semplicemente che il codice del client è scritto contro l'interfaccia della classe base, ed è quindi disaccoppiato dall'implementazione concreta di Singleton (non ne è a conoscenza). Questa è solo inversione di dipendenza presente in molti altri modelli. Immagino che lo includessero come, se non hai bisogno di sottoclassi, puoi semplicemente usare una classe statica (come in C #), o un mucchio di metodi gratuiti + qualche stato globale, o qualcosa del genere.
In questo approccio, uno dei problemi è come configurare il metodo GetInstance () (o equivalente) per restituire l'implementazione concreta corretta.
Detto questo, si noti che Singleton è considerato da molti un antipattern, la ragione principale è che un Singleton, come normalmente implementato, è essenzialmente una variabile globale, quindi tutto il codice che lo utilizza può diventare implicitamente accoppiato.
Qualcuno può chiarire il secondo punto? probabilmente no.
Il documento GoF continua a dire:
Subclassing the Singleton class. The main issue is not so much defining the subclass but installing its unique instance so that clients will be able to use it. In essence, the variable that refers to the singleton instance must get initialized with an instance of the subclass.
Quindi prosegue suggerendo tre modi per farlo. Nessuno dei quali è davvero buono.
Inserisci un'istruzione If nella classe Singleton
Inserisci GetInstance per la sottoclasse singleton in una classe diversa e collega la classe che desideri utilizzare durante la compilazione
Aggiungi una funzione di registro che imposta il singleton e può prendere una sottoclasse.
Il mio consiglio è di ignorare il secondo punto. Usare un singleton nel significato moderno del termine significa che non puoi sostituirlo con una sottoclasse senza modificare efficacemente la classe originale.
Tuttavia dovrei prendere una nota importante. Se si esegue il percorso di registrazione si sta effettivamente creando un contenitore DI per quella singola classe. Invece di usare il modello singleton, dovresti registrare la classe che desideri utilizzare come un singleton, (diversi contenitori chiamano queste cose diverse) nel tuo contenitore DI.
Questo non impedisce realmente due istanze della classe esistenti allo stesso tempo, ma è la migliore alternativa.
Leggi altre domande sui tag object-oriented design-patterns object-oriented-design singleton