Esistono valide alternative al pattern GOF Singleton?

Affrontiamolo. Il Singleton Pattern è un argomento molto controverso con orde di programmatori su entrambi i lati della barriera. Ci sono quelli che pensano che il Singleton non sia altro che una variabile globale glorificata, e altri che giurano per modello e lo usano incessantemente. Tuttavia, non voglio che la controversia Singleton sia al centro della mia domanda. Tutti possono fare un tiro alla fune e combattere e vedere chi vince per quanto mi riguarda . Quello che sto cercando di dire è che non credo ci sia una sola risposta corretta e non sto intenzionalmente cercando di infiammare i litigi partigiani. Sono semplicemente interessato alle alternative singleton quando pongo la domanda:

Ci sono alternative specifiche al pattern GOF Singleton?

Ad esempio, molte volte quando ho utilizzato il pattern singleton in passato, mi interessa semplicemente preservare lo stato / i valori di una o più variabili. Lo stato / i valori delle variabili, tuttavia, possono essere conservati tra ogni istanziazione della classe utilizzando variabili statiche invece di utilizzare il pattern singleton.

Che altra idea hai?

EDIT: Non voglio davvero che questo sia un altro post su "come usare correttamente il singleton". Di nuovo, sto cercando modi per evitarlo. Per divertimento, ok? Immagino di fare una domanda puramente accademica nella tua migliore voce per il trailer di un film, "In un universo parallelo dove non c'è il singleton, cosa potremmo fare?"

Alex Miller in " Patterns I Hate " cita quanto segue:

"Quando un singleton sembra la risposta, trovo che spesso sia più saggio:

1. Crea un'interfaccia e un'implementazione predefinita del tuo singleton
2. Costruisci una singola istanza della tua implementazione predefinita nella "parte superiore" del tuo sistema. Questo potrebbe essere in una configurazione Spring, o nel codice, o definito in una varietà di modi a seconda del sistema.
3. Passa la singola istanza in ogni componente che ne ha bisogno (inserimento delle dipendenze)

Per capire il modo corretto di aggirare i Singleton, devi capire cosa c'è di sbagliato in Singleton (e nello stato globale in generale):

I single nascondono le dipendenze.

Perché è così importante?

Perché se nascondi le dipendenze tendi a perdere di vista la quantità di accoppiamento.

Potresti sostenerlo

void purchaseLaptop(String creditCardNumber, int price){
  CreditCardProcessor.getInstance().debit(creditCardNumber, amount);
  Cart.getInstance().addLaptop();
}

è più semplice di

void purchaseLaptop(CreditCardProcessor creditCardProcessor, Cart cart, 
                    String creditCardNumber, int price){
  creditCardProcessor.debit(creditCardNumber, amount);
  cart.addLaptop();
}

ma almeno la seconda API rende chiaro esattamente quali sono i collaboratori del metodo.

Quindi il modo per aggirare Singletons non è usare variabili statiche o localizzatori di servizi, ma cambiare le classi Singleton in istanze, che vengono istanziate nell'ambito in cui hanno senso e iniettate nei componenti e nei metodi che ne hanno bisogno. Potresti usare un framework IoC per gestirlo, oppure potresti farlo manualmente, ma la cosa importante è sbarazzarti del tuo stato globale e rendere esplicite le dipendenze e le collaborazioni.

La soluzione migliore che ho trovato è usare il pattern factory per costruire istanze delle tue classi. Usando il pattern, puoi assicurarti che c'è solo un'istanza di una classe condivisa tra gli oggetti che la usano.

Pensavo che sarebbe stato complicato da gestire, ma dopo aver letto questo post sul blog "Where Have All the Singletons Gone?" , sembra così naturale. E per inciso, aiuta molto a isolare i tuoi unit test.

In sintesi, cosa devi fare? Ogni volta che un oggetto dipende da un altro, ne riceverà un'istanza solo tramite il suo costruttore (nessuna nuova parola chiave nella tua classe).

class NeedyClass {

    private ExSingletonClass exSingleton;

    public NeedyClass(ExSingletonClass exSingleton){
        this.exSingleton = exSingleton;
    }

    // Here goes some code that uses the exSingleton object
}

E poi, la fabbrica.

class FactoryOfNeedy {

    private ExSingletonClass exSingleton;

    public FactoryOfNeedy() {
        this.exSingleton = new ExSingletonClass();
    }

    public NeedyClass buildNeedy() {
        return new NeedyClass(this.exSingleton);
    }
}

Poiché istanzerai la tua factory solo una volta, ci sarà un'unica istanza di exSingleton. Ogni volta che chiami buildNeedy, la nuova istanza di NeedyClass verrà fornita in bundle con exSingleton.

Spero che aiuti. Si prega di segnalare eventuali errori.

Spring o qualsiasi altro contenitore IoC fa un lavoro ragionevolmente buono in questo. Poiché le classi vengono create e gestite all'esterno dell'app stessa, il contenitore può creare semplici singole classi e iniettarle dove necessario.

Non dovresti fare di tutto per evitare qualsiasi schema. L'uso di un modello è una decisione di progettazione o una scelta naturale (va semplicemente a posto). Quando si progetta un sistema, è possibile scegliere se utilizzare un pattern o non utilizzare il pattern. Tuttavia, non dovresti fare di tutto per evitare tutto ciò che in definitiva è una scelta di design.

Non evito il Singleton Pattern. O è appropriato e lo uso o non è appropriato e non lo uso. Credo che sia così semplice.

L'adeguatezza (o la mancanza di ciò) del Singleton dipende dalla situazione. È una decisione progettuale che deve essere presa e le conseguenze di tale decisione devono essere comprese (e documentate).

Monostate (descritto in Agile Software Development di Robert C. Martin) è un'alternativa al singleton. In questo modello i dati della classe sono tutti statici ma i getter / setter non sono statici.

Per esempio:

public class MonoStateExample
{
    private static int x;

    public int getX()
    {
        return x;
    }

    public void setX(int xVal)
    {
        x = xVal;
    }
}

public class MonoDriver
{
    public static void main(String args[])
    {
        MonoStateExample m1 = new MonoStateExample();
        m1.setX(10);

        MonoStateExample m2 = new MonoStateExample();
        if(m1.getX() == m2.getX())
        {
            //singleton behavior
        }
    }
}

Monostate ha un comportamento simile al singleton ma lo fa in un modo in cui il programmatore non è necessariamente consapevole del fatto che viene utilizzato un singleton.

Il modello singleton esiste perché ci sono situazioni in cui è necessario un singolo oggetto per fornire un insieme di servizi .

Anche se questo è il caso, continuo a considerare l'approccio di creare singleton utilizzando un campo / proprietà statico globale che rappresenta l'istanza, inappropriato. Non è appropriato perché crea una dipendenza nel codice tra il campo statico e l'oggetto no, i servizi forniti dall'oggetto.

Quindi, invece del classico pattern singleton, ti consiglio di utilizzare il pattern "like" del servizio con i contenitori serviti , dove invece di utilizzare il tuo singleton attraverso un campo statico, ottieni un riferimento ad esso tramite un metodo che richiede il tipo di servizio richiesto.

*pseudocode* currentContainer.GetServiceByObjectType(singletonType)
//Under the covers the object might be a singleton, but this is hidden to the consumer.

invece di un singolo globale

*pseudocode* singletonType.Instance

In questo modo, quando vuoi cambiare il tipo di un oggetto da singleton a qualcos'altro, avrai e facile farlo. Inoltre, come ulteriore vantaggio, non è necessario trasferire molte istanze di oggetti a ogni metodo.

Vedi anche Inversion of Control , l'idea è che esponendo i singleton direttamente al consumatore, crei una dipendenza tra il consumatore e l'istanza dell'oggetto, non i servizi dell'oggetto forniti dall'oggetto.

La mia opinione è di nascondere l'uso del pattern singleton ogni volta che è possibile, perché non è sempre possibile evitarlo, o auspicabile.

Se stai usando un Singleton per rappresentare un singolo oggetto dati, potresti invece passare un oggetto dati come parametro del metodo.

(anche se, direi che questo è il modo sbagliato di usare un Singleton in primo luogo)

Se il tuo problema è che vuoi mantenere lo stato, vuoi una classe MumbleManager. Prima di iniziare a lavorare con un sistema, il tuo client crea un MumbleManager, dove Mumble è il nome del sistema. Lo stato viene mantenuto attraverso quello. È probabile che il tuo MumbleManager conterrà una borsa delle proprietà che contiene il tuo stato.

Questo tipo di stile sembra molto simile a C e non molto simile a un oggetto: scoprirai che gli oggetti che definiscono il tuo sistema avranno tutti un riferimento allo stesso MumbleManager.

Usa un oggetto semplice e un oggetto di fabbrica. La fabbrica è responsabile del controllo dell'istanza e dei dettagli dell'oggetto semplice solo con le informazioni di configurazione (contiene ad esempio) e il comportamento.

In realtà, se si progetta da zero evitando i Singeltons, potrebbe non essere necessario aggirare il problema di non utilizzare Singleton utilizzando variabili statiche. Quando si utilizzano variabili statiche, si crea anche più o meno un Singleton, l'unica differenza è che si creano istanze di oggetti diverse, tuttavia internamente si comportano tutti come se utilizzassero un Singleton.

Puoi forse fornire un esempio dettagliato in cui utilizzi un singleton o dove viene attualmente utilizzato un singleton e stai cercando di evitare di usarlo? Questo potrebbe aiutare le persone a trovare una soluzione più elaborata su come la situazione potrebbe essere gestita senza un Singleton.

A proposito, personalmente non ho problemi con i Singleton e non riesco a capire i problemi che le altre persone hanno riguardo ai Singleton. Non vedo niente di male in loro. Cioè, se non li stai abusando. Ogni tecnica utile può essere abusata e, se abusata, porterà a risultati negativi. Un'altra tecnica comunemente usata in modo improprio è l'ereditarietà. Eppure nessuno direbbe che l'eredità sia qualcosa di negativo solo perché alcune persone ne abusano orribilmente.

Personalmente per me un modo molto più sensato per implementare qualcosa che si comporta come singleton è usare una classe completamente statica (membri statici, metodi statici, proprietà statiche). Il più delle volte lo implemento in questo modo (non riesco a pensare a differenze di comportamento dal punto di vista dell'utente)

Penso che il posto migliore per sorvegliare il singleton sia a livello di design di classe. In questa fase, dovresti essere in grado di mappare le interazioni tra le classi e vedere se qualcosa di assolutamente, sicuramente richiede che solo 1 istanza di questa classe sia mai presente in qualsiasi momento della vita dell'applicazione.

Se è così, allora hai un singleton. Se stai inserendo singleton per comodità durante la codifica, dovresti davvero rivisitare il tuo design e anche smettere di codificare detti singleton :)

E sì, "polizia" è la parola che intendevo qui piuttosto che "evitare". Il singleton non è qualcosa da evitare (allo stesso modo in cui goto e le variabili globali non sono qualcosa da evitare). Invece, dovresti monitorare il suo utilizzo e assicurarti che sia il metodo migliore per ottenere ciò che desideri sia fatto in modo efficace.

Uso singleton principalmente come "contenitore di metodi", senza alcuno stato. Se ho bisogno di condividere questi metodi con molte classi e voglio evitare il peso della creazione di istanze e inizializzazione, creo un contesto / sessione e inizializzo tutte le classi lì; tutto ciò che si riferisce alla sessione ha accesso anche al "singleton" così contenuto.

Non avendo programmato in un ambiente intensamente orientato agli oggetti (ad esempio Java), non sono completamente d'accordo sulle complessità della discussione. Ma ho implementato un singleton in PHP 4. L'ho fatto come un modo per creare un gestore di database "scatola nera" che si inizializzava automaticamente e non doveva essere passato su e giù per le chiamate di funzione in un framework incompleto e in qualche modo rotto.

Avendo letto alcuni link di pattern singleton, non sono del tutto sicuro che lo implementerei di nuovo nello stesso modo. Ciò che era veramente necessario erano più oggetti con archiviazione condivisa (ad esempio l'handle del database effettivo) e questo è praticamente ciò in cui si è trasformata la mia chiamata.

Come la maggior parte dei modelli e degli algoritmi, usare un singleton "solo perché è bello" è The Wrong Thing To Do. Avevo bisogno di una chiamata veramente "scatola nera" che somigliasse molto a un singleton. E IMO questo è il modo per affrontare la domanda: sii consapevole del modello, ma guarda anche al suo ambito più ampio ea quale livello l'istanza deve essere unica.

Cosa vuoi dire, quali sono le mie tecniche per evitarlo?

Per "evitarlo", ciò implica che ci sono molte situazioni in cui mi imbatto in cui il pattern singleton è naturalmente un buon adattamento, e quindi devo prendere alcune misure per disinnescare queste situazioni.

Ma non ci sono. Non devo evitare il pattern singleton. Semplicemente non si presenta.