Utilizzare correttamente il modello di progettazione singleton

Question

Sto eseguendo un server che a volte deve cercare ciò che un client richiede. Mi piacerebbe scrivere la query del client sul disco per i record, ma non voglio rallentare la ricerca più di quanto sia necessario. (La ricerca è già il collo di bottiglia ...)

Quindi, quando il client esegue una ricerca, sto facendo in modo che il thread del client invii un messaggio a un thread singleton, che gestirà la scrittura del disco, mentre il thread del client continua a gestire le richieste del cliente. In questo modo, il file su disco non ha problemi di sincronizzazione e non rallenta l'esperienza dei client.

Ho una domanda concettuale qui: il singleton è appropriato in questo caso? Ho usato un po 'troppo il pattern di progettazione del singleton nella mia recente programmazione, e voglio assicurarmi che lo stia usando per l'uso previsto.

Qualsiasi feedback è molto apprezzato.

Answer 1

Il singleton pattern è decisamente sovrautilizzato e viene fornito con la sua quota di difficulties (unit test è l'esempio canonico), ma come tutto nel design, è necessario valutare i pro ei contro per il proprio scenario specifico. Il modello singleton ha i suoi usi. Esistono opzioni che possono consentire di ottenere il comportamento singleton, attenuando alcuni dei problemi inerenti:

Interception (spesso definito come programmazione orientata all'aspetto, anche se ho visto il dibattito che non sono esattamente la stessa cosa. .. non riesco a trovare l'articolo che ho letto su questo in questo momento) è sicuramente un'opzione. È possibile utilizzare qualsiasi combinazione di iniezione di costruzione, il modello decorator, una fabbrica astratta e uno inversion of control container. Non sono nei miei contenitori Java IoC, ma ci sono alcuni contenitori .Net che consentono l'intercettazione automatica (credo che Spring.Net lo faccia, quindi Spring (Java) ha questo built-in). Questo è molto utile per qualsiasi tipo di preoccupazioni trasversali, in cui è necessario eseguire determinati tipi di azioni su più livelli (sicurezza, registrazione, ecc.). Inoltre, la maggior parte dei contenitori IoC ti consente di controllare la gestione a vita, in modo da poter trattare il tuo registratore come un singleton, senza dover effettivamente implementare manualmente il modello singleton.

Per riassumere. Se un singleton si adatta al tuo scenario (sembra plausibile dalla tua descrizione), provaci. Assicurati solo di aver valutato i pro e i contro. Potresti provare un approccio diverso e confrontare i due.