Va bene avere molte dipendenze in una classe che solo delega funziona?

5

Sto esaminando il codice del più grande programma che io abbia mai creato da zero e vedendo se ci sono cose che posso migliorare nel design. Quando ho creato il programma per la prima volta stavo usando Singleton ovunque, ma da allora li ho rimossi completamente e invece passati a usare Dependency Injection. Una cosa che ho notato è che alcune delle classi hanno una specie di contrasti muscolosi da quando ho iniettato tutte le classi necessarie. Ad esempio, ho una classe che legge i messaggi da una porta seriale e li salva in una coda di messaggi. Poi ho una classe chiamata MessageHandler che raccoglie i messaggi dalla coda e li delega alla parte corretta del sistema. Attualmente questa classe MessageHandler ha sei classi immesse nel costruttore. Va bene per una classe che fondamentalmente semplicemente inoltra i messaggi al destinatario corretto o è un segnale che devo ripensare al mio design?

    
posta Jesper Evertsson 27.02.2017 - 16:13
fonte

3 risposte

5

Vuoi mantenere bassa la quantità di dipendenze. Una classe con molte dipendenze probabilmente viola la separazione delle preoccupazioni.

Ma non esiste una regola ferrea su quante dipendenze siano troppe. Sei dipendenze non mi sembrano subito un problema, dipende molto dal singolo caso.

Non è di per sé un problema se una classe non fa altro che delegare. Questo è ad esempio quello che fa il modello dell'adattatore.

    
risposta data 27.02.2017 - 16:33
fonte
4

Is it ok to have a many dependencies in a class that just delegates work?

(a patto che appartengano davvero a loro)

Non penso che avere una classe con molti campi sia una brutta cosa. È una fase intermedia come parte del normale refactoring. Il passo successivo è in genere l'identificazione di classi che sono generalmente insieme in luoghi diversi e che le avvolgono nel proprio oggetto / classe.

La mia regola empirica è di 3 classi ma non ne sono troppo dogmatico. Finché vengono iniettati oggetti di stato (con una configurazione sensata) anziché creati da un etere sottile (Singleton / Static Factories), va bene.

    
risposta data 27.02.2017 - 16:24
fonte
0

Nel mondo del software, esiste un modello di progettazione per risolvere esattamente questo problema (proprio come qualsiasi altro problema software comune). Si chiama il modello dell'adattatore. E a meno che il tuo codice di inizializzazione e di accesso non usi una sorta di stregoneria (leggi: Reflection), sì, avrà molte dipendenze tra i moduli.

Bene, almeno i moduli che ospitano le vostre fabbriche di servizi. L'idea di tutto ciò che è, in futuro, potrebbe essere necessario per sostituire un modulo con solo un altro. Poiché l'interfaccia al modulo non dovrebbe cambiare (per compatibilità con le versioni precedenti), si può supporre che gli adattatori non cambieranno, ad eccezione della nuova serie di dipendenze, necessaria per inizializzare i nuovi servizi.

L'adattatore dovrebbe essere una soluzione unica per la comunicazione tra moduli, nel frattempo anche promettendo un design a prova di futuro. Il motivo che consente all'adattatore di essere un tuttologo è che loro stessi possono accedere a molti altri servizi (direttamente o tramite una stregoneria) per fare in modo che il cliente faccia ciò che vuole.

Nota la distinzione tra gli adattatori e le facciate, anche se potrebbero sembrare strutturalmente simili, ma sono nati per servire a scopi disparati. La facciata ha meno a che fare con la dipendenza e più con il design pulito per evitare di offuscare i clienti.

    
risposta data 27.02.2017 - 16:51
fonte

Leggi altre domande sui tag