Singleton - Creational Pattern

Il Problema

A volte è necessario che una classe abbia esattamente una sola istanza. Ad esempio, ci dovrebbe essere un solo oggetto per gestire la connessione al database, un solo logger di sistema, o un solo gestore di configurazione.

La Soluzione

Rendere la classe responsabile di tenere traccia della sua unica istanza. La classe impedisce la creazione di altre istanze intercettando le richieste di creazione e fornendo un metodo per accedere all'istanza unica.

Struttura

Una classe con un costruttore privato, una variabile statica privata per contenere l'istanza unica, e un metodo statico pubblico per ottenere l'istanza.

Partecipanti:

Singleton - definisce il metodo getInstance() che restituisce l'istanza unica

Instance - l'istanza unica della classe Singleton

Esempi di Codice

PROBLEMA: Senza Singleton - Istanze Multiple

Questo codice crea molteplici istanze della configurazione, causando inconsistenza e spreco di memoria.

SOLUZIONE: Singleton - Una Sola Istanza

Il pattern Singleton garantisce che esista una sola istanza e fornisce un punto di accesso globale.

Esempio Pratico: Database Connection Pool

Caso d'uso reale: pool di connessioni al database condiviso in tutta l'app.

Confronto: Singleton vs Istanze Multiple

Visualizzazione delle differenze tra i due approcci.

Esempi nel Mondo Reale

Database Connection Pool - Una sola istanza gestisce tutte le connessioni al database

Logger di sistema - Un solo logger centralizzato per tutta l'applicazione

Configuration Manager - Configurazione globale accessibile ovunque

Cache Manager - Una sola cache condivisa tra tutti i componenti

Thread Pool - Gestione centralizzata dei thread worker

Quando Usarlo

Quando deve esserci esattamente una sola istanza di una classe

Quando l'istanza deve essere accessibile da più parti del codice

Quando l'istanza unica dovrebbe essere estendibile tramite sottoclassi

Per gestire risorse condivise (database, file, configurazioni)

Quando NON Usarlo

Quando servono istanze multiple con stato diverso

Quando rende difficile il testing (dependency injection è meglio)

Quando crea accoppiamento stretto nel codice

Quando viola il Single Responsibility Principle

Pattern Correlati