Aiutami a rimuovere un Singleton: cercare un'alternativa

Question

Background: Ho alcune classi che implementano un pattern di progettazione soggetto/osservatore che ho reso thread-safe. Un subject notificherà il suo observers con una semplice chiamata di metodo observer->Notified(this) se lo observer è stato creato nello stesso thread della notifica. Ma se lo observer è stato costruito in un thread diverso, la notifica verrà registrata su un queue per essere elaborata in seguito dal thread che ha creato lo observer e quindi è possibile effettuare la chiamata al metodo semplice quando viene elaborato l'evento di notifica.

Quindi ... Ho una mappa che associa thread e code che vengono aggiornati quando thread e code sono costruiti e distrutti. Questa mappa utilizza un mutex per proteggere l'accesso multi-thread ad esso.

La mappa è un singleton.

Sono stato colpevole di usare singoletti in passato perché "ce ne sarà solo uno in questa applicazione" e, credetemi, ho pagato la mia penitenza!

Una parte di me non può fare a meno di pensare che in un'applicazione ci sarà solo una mappa code/thread. L'altra voce dice che i singleton non sono buoni e dovresti evitarli.

Mi piace l'idea di rimuovere il singleton e di poterlo mozzare per i miei test di unità. Il problema è che sto attraversando un periodo difficile cercando di pensare a una buona soluzione alternativa.

La "solita" soluzione che ha funzionato in passato consiste nel passare un puntatore all'oggetto da utilizzare invece di fare riferimento al singleton. Penso che sarebbe difficile in questo caso, dal momento che osservatori e soggetti sono 10 penny nella mia applicazione e sarebbe molto imbarazzante dover passare un oggetto mappa coda/thread nel costruttore di ogni singolo osservatore.

Ciò che apprezzo è che potrei avere una sola mappa nella mia applicazione, ma non dovrebbe essere nelle viscere del codice della classe oggetto e osservatore in cui tale decisione è presa.

Forse questo è un singleton valido, ma apprezzerei anche qualsiasi idea su come potrei rimuoverlo.

Grazie.

PS. Ho letto What's Alternative to Singleton e this article menzionato nella risposta accettata. Non posso fare a meno di pensare che ApplicationFactory sia solo un altro singleton con un altro nome. Io davvero non vedo il vantaggio.

Answer 1

Gli osservatori possono essere economici, ma dipendono dalla mappa della coda di notifica, giusto?

Cosa c'è di strano nel rendere esplicita tale dipendenza e assumerne il controllo?

Per quanto riguarda la fabbrica di applicazioni che Miško Hevery descrive nel suo articolo, i maggiori vantaggi sono che 1) l'approccio di fabbrica non nasconde le dipendenze e 2) le singole istanze da cui si dipende non sono globalmente disponibili in modo tale che qualsiasi altro oggetto può interferire con il loro stato. Quindi, utilizzando questo approccio, in qualsiasi contesto applicativo di primo livello, sai esattamente cosa sta usando la tua mappa. Con un singleton globalmente accessibile, qualsiasi classe che usi potrebbe fare cose sgradevoli con o sulla mappa.

Answer 2

Alcuni pensieri verso una soluzione:

Perché avete bisogno di accodare le notifiche per gli osservatori che sono stati creati su un thread diverso?Il mio progetto preferito sarebbe quello di fare in modo che lo subject notifichi direttamente gli osservatori e metta l'onere sugli osservatori per implementare i thread in sicurezza, con la consapevolezza che Notified() potrebbe essere chiamato in qualsiasi momento da un altro thread. Gli osservatori sanno quali parti del loro stato devono essere protette con serrature e possono gestirle meglio di subject o queue.

Supponendo che si abbia davvero una buona ragione per mantenere lo queue, perché non renderlo un'istanza? Basta fare queue = new Queue() da qualche parte in main e quindi passare intorno a tale riferimento. Può essercene solo uno, ma è comunque possibile considerarlo come un'istanza e non come una statica globale.

Answer 3

Cosa c'è di sbagliato nel mettere la coda nella classe oggetto? A cosa serve la mappa?

Hai già una lettura di thread dalla mappa coda singleton. Invece di fare che semplicemente rendono la mappa all'interno della classe soggetto e fornire due metodi di sottoscrivere un osservatore:

class Subject 
{ 
    // Assume is threadsafe and all 
    private QueueMap queue; 
    void Subscribe(NotifyCallback, ThreadId) 
    { 
    // If it was created from another thread add to the map 
    if (ThreadId != This.ThreadId) 
     queue[ThreadId].Add(NotifyCallback); 
    } 

    public NotifyCallBack GetNext() 
    { 
    return queue[CallerThread.Id].Pop; 
    } 
} 

Ora, qualsiasi thread può chiamare il metodo GetNext per iniziare dispacciamento ... ovviamente è tutto eccessivamente semplificata, ma è solo l'idea.

Nota: sto lavorando con il presupposto che si dispone già di un'architettura intorno a questo modello in modo che si dispone già di un gruppo di osservatori, uno o più soggetti e che i fili già andate alla mappa per fare il notifiche. Questo elimina il singleton ma ti suggerisco di notificare dallo stesso thread e lasciare che gli osservatori gestiscano i problemi di concorrenza.

Answer 4

Il mio approccio era quello di fare in modo che gli osservatori mettessero una coda quando si registravano con il soggetto; proprietario dell'osservatore sarebbe responsabile sia per il filo e la coda associata, e il soggetto avrebbe associare l'osservatore con la coda, senza la necessità di un registro centrale.

Gli osservatori thread-safe potevano registrarsi senza coda e essere chiamati direttamente dal soggetto.

Answer 5

Se l'unico scopo di cercare di liberarsi del Singleton è dal punto di vista test di unità, forse sostituendo il getter Singleton con qualcosa che è possibile scambiare in uno stub per.

class QueueThreadMapBase 
{ 
    //virtual functions 
}; 

class QeueueThreadMap : public QueueThreadMapBase 
{ 
    //your real implementation 
}; 

class QeueueThreadMapTestStub : public QueueThreadMapBase 
{ 
    //your test implementation 
}; 

static QueueThreadMapBase* pGlobalInstance = new QeueueThreadMap; 

QueueThreadMapBase* getInstance() 
{ 
    return pGlobalInstance; 
} 

void setInstance(QueueThreadMapBase* pNew) 
{ 
    pGlobalInstance = pNew 
} 

Poi, nel tuo test appena scambiare l'attuazione di code/thread. Per lo meno questo espone il singleton un po 'di più.

Answer 6

Che dire di aggiungere un metodo di ripristino che restituisce un singleton al suo stato iniziale che è possibile chiamare tra i test? Potrebbe essere più semplice di uno stub. Potrebbe essere possibile aggiungere un metodo di ripristino generico a un modello Singleton (elimina il pimpl Singleton interno e reimposta il puntatore). Questo potrebbe anche includere un registro di tutti i single con un metodo maestro ResetAll per ripristinare tutti loro!