Questo articolo illustra in che modo il modello Singleton applica solo una singola istanza di una classe per essere prodotta ed esistere per tutta la durata di un'applicazione.

Che cos'è?

Un singleton è un modello di progettazione utilizzato per creare l'unica istanza di classe. Il modello Singleton viene in genere utilizzato quando sono presenti diversi esempi in cui dovrebbe esistere solo una singola istanza di una classe e il vincolo deve essere applicato. Ad esempio, cache, pool di thread e registri dovrebbero avere una sola istanza.

Rendi privato il costruttore per assicurarti che venga creato un solo oggetto di classe. In questo modo, solo i membri della classe possono accedere al costruttore privato e nessun altro.

Nel mondo reale, il modello Singleton assicura che esista una sola istanza di classe e offre un punto di accesso globale ad essa.

Diagramma di classe

Il diagramma di classe contiene solo un'entità.

Singleton

Esempio

Diciamo che vogliamo modellare l'aereo ufficiale del presidente americano chiamato Airforce One nel nostro software. La classe Singleton è la rappresentazione più adatta per un'entità con una sola istanza.

Ecco il codice per la nostra classe singleton:

Multithreading e Singleton

Questo codice funziona finché l'applicazione è a thread singolo. Tuttavia, se più thread accedono a questa classe, è possibile che vengano creati vari oggetti.

Per esempio:

• Il thread A chiama il metodo getInstancee trova onlyInstancenull; tuttavia, prima che possa creare un'istanza, viene disattivato il contesto.
• Ora arriva il thread B e chiama getInstance, che restituisce l' AirforceOneoggetto.
• Se il thread A viene programmato di nuovo, inizia il guaio. Il thread ha già superato il controllo della condizione if-null e procederà a creare un nuovo AirforceOneoggetto e ad assegnarlo a onlyInstance. Ora ci sono due diversi AirforceOneoggetti allo stato brado, uno con filo A e uno con filo B.

• Aggiungendo synchronizedal getInstance()metodo, puoi ottenere la sicurezza del thread.

• Un'altra opzione consiste nell'inizializzare l'istanza in modo statico, garantendo che sia thread-safe.

Chiusura a doppio controllo

Esistono due problemi significativi con gli approcci sopra descritti: la sincronizzazione è costosa e l'inizializzazione statica crea l'oggetto anche se non viene utilizzato in una particolare esecuzione dell'applicazione. Se la creazione dell'oggetto è costosa, l'inizializzazione statica può costarci le prestazioni.

La soluzione precedente contrassegna l'istanza singleton come volatile. Tuttavia, questa implementazione della volatilemetodologia della JVM non funzionerà correttamente per il blocco a doppio controllo e avrai bisogno di un altro approccio per creare i tuoi singleton.

L' idioma di blocco a doppio controllo è ora considerato un antipattern e la sua utilità è principalmente scomparsa con l'accelerazione dei tempi di avvio di JVM.

Altri esempi

L'API Java ci fornisce i seguenti singleton:

java.lang.Runtime

java.awt.Desktop

Avvertenze

Puoi creare una sottoclasse di una classe singleton proteggendo il costruttore anziché private. Tuttavia, ci sono scelte migliori di questa in tutte le circostanze. In queste situazioni, gli sviluppatori possono creare un registro di singleton per tutte le sottoclassi. Il metodo getInstance può accettare un parametro o utilizzare una variabile di ambiente per restituire l'oggetto singleton desiderato. Il registro mantiene una mappatura dei nomi delle stringhe agli oggetti singleton.

Altri articoli nella serie Creational Pattern

• Modello Creativo: Costruttore
• Modello Creativo: Prototipo
• Modello di creazione: metodo di fabbrica
• Schema Creativo: Fabbrica Astratta