Hai bisogno di un singleton?
Secondo GoF , l'intento di un singleton è:
to ensure that a class has only a single instance and to provide
an access point to it.
Ma esiste una ragione che giustifichi che un RequestUser in realtà debba essere univoco nella tua applicazione? O era solo una scelta progettuale perché era comodo ritrovare facilmente l'utente attivo, supponendo che il cliente sarebbe stato per un singolo utente? E se sì, non riesci a immaginare una versione futura del tuo cliente che si connetterebbe a diverse fonti di informazioni e le combinasse, quindi necessitando di più%% di% attivo?
Non usare un singleton, a meno che non sia necessario. La comodità di ritrovarlo è più che compensata dalle molte dipendenze nascoste che favorisce.
È davvero un'eredità?
Non mi è chiaro se:
-
RequestUsers eredita da RequestUser perché hai un backend stateful e Request è in realtà un% distintoRequestUser,
- o se vuoi solo
Request ereditare da un paio di comportamenti, come ad esempio la formattazione di una parte URL che verrà combinata con altre parti per costruire la richiesta reale.
Nel primo caso, l'ereditarietà va bene. Nel secondo, non è un progetto sicuro e dovresti favorire la composizione. In entrambi i casi, tuttavia, si crea una dipendenza strutturale tra il client e la logica di back-end in termini di sequenza di operazioni e schema di comunicazione.
Progettazione alternativa: il mediatore
Potresti disaccoppiare i tuoi componenti molto di più optando per il schema del mediatore .
Con questo modello, l'utente, l'evento e gli altri argomenti delle richieste diventerebbero colleghi, ereditando da una classe base che fornisce il comportamento comune.
Un mediatore potrebbe quindi incapsulare le interazioni tra i colleghi. Quell'oggetto, e solo quell'oggetto, dovrebbe quindi trovare l'utente corrente objet per la richiesta corrente e gestire esplicitamente questo tipo di dipendenze.
Potrebbe essere difficile cambiare il tuo attuale modo di pensare. Tuttavia questo schema vale davvero l'investimento: perché una volta che il mediatore incapsula le interazioni, non devi più preoccuparti se si tratta di un backend statico o stateless in qualsiasi altro punto del tuo codice: il mediatore combinerebbe i comportamenti come richiesto.
