Nome per il pattern singleton modificato di Osherove?

È un Singleton combinato con un metodo di fabbrica , in modo tale che il codice chiamante non abbia idea che stia trattando con un singleton, o anche con la classe con cui ha a che fare. Persino la classe stessa non sa che è un Singleton. La fabbrica può essere messa alla prova, rendendo possibile il test ma, nel contesto dell'applicazione, è sempre lo stesso oggetto restituito.

Ho visto alcuni siti chiamarlo Singleton Factory , per distinguere i due.

È ormai normale prendere questo tipo di decisione (a volte pericolosamente, come se non si trattasse più di un Singleton vero, quindi non importa) nel processo di registrazione degli oggetti con un contenitore IoC, rendendo nome in gran parte irrilevante.

È il modello singleton. La sua descrizione come un progetto non sarebbe diversa dal singleton originale. È solo una variante di implementazione.

Il "modello singleton" racchiude un paio di concetti diversi: (1) una sorta di oggetto è implicitamente condiviso; (2) l'oggetto può essere creato pigramente senza modificare lo stato del sistema osservabile. Mentre questi concetti vanno spesso insieme, alcune applicazioni useranno l'una senza l'altra.

Ad esempio, un sistema può utilizzare una variabile thread-static per contenere un riferimento al database corrente. Quando viene avviato ogni thread che necessiterà della base dati, acquisisce una copia di un'impostazione globale "database corrente" e la utilizza per ottenere un riferimento al database corrente che verrà quindi utilizzato fino al completamento. Poiché molti metodi utilizzeranno tutti il database corrente, il passaggio esplicito di un riferimento ad esso potrebbe essere complicato e dire "tutti i metodi operano sul database corrente del thread, come definito da _ " potrebbe essere il codice più pulito di dover passare esplicitamente un riferimento al database con ogni chiamata di funzione. Nota che in questo scenario, c'è un oggetto che è condiviso implicitamente, ma la sua creazione altera lo stato del sistema.

In alternativa, un programma può avere una varietà di istanze statiche di oggetti che implementano IGetGlobalWidget con un metodo virtuale GetWidget . Questi oggetti, essendo statici, vengono creati all'avvio del programma anziché essere generati pigramente e ciascuno di questi oggetti, se utilizzati, genererà pigramente (se necessario) una sorta di derivata Widget e restituirà un riferimento ad esso. Piuttosto che passare circa Widget riferimenti, il codice passa attorno ai riferimenti alle implementazioni di IGetGlobalWidget . Qualsiasi implementazione IGetGlobalWidget specifica restituirà sempre la stessa Widget istanza -derivativa e la creazione lazy non influirà sullo stato del programma visibile, ma il codice potrebbe controllare quali metodi condivideranno i widget, con cui i metodi condividono IGetGlobalWidget objects.