Suggerimenti / consigli su come ridurre l'uso delle classi "manager"?

A volte ho sentito che avere troppe classi "manager" nella progettazione del tuo programma è odore di codice e aggiunge un inutile livello di complessità. Per me ha senso che le persone vogliano usare le classi manager per manipolare e controllare gli oggetti da un contesto che ha senso per loro, ma capire come far funzionare una soluzione senza di loro può essere fonte di confusione.

Bisogna davvero evitare il più possibile le classi manageriali? Inoltre, quali articoli / documenti dovrei leggere su come implementare una soluzione alternativa per casi generali / comuni in cui questi manager possono essere rimossi?

Ci sono forse due ragioni per cui questo è un odore di codice. Uno dei motivi è che ciò può significare che non si hanno oggetti di dominio ma si hanno invece oggetti di valore che memorizzano solo dati per la manipolazione da parte di controller o classi manager. Questo è in realtà abbastanza comune e equivale alla programmazione procedurale in un linguaggio OO. I "molti gestori" possono suggerire che è necessario integrare la logica di stato, la convalida e altre preoccupazioni dirette negli oggetti del dominio in modo che incapsulino effettivamente qualcosa. Naturalmente ci sono suggerimenti più grandi come il fatto che non hai metodi diversi da getter / setter.

L'altro motivo è un odore di codice è che potrebbe significare che i tuoi oggetti di dominio non si relazionano molto bene tra loro. Ad esempio, se disponi di una classe Account che in realtà non sa nulla della classe Transaction, tranne per il fatto che è denominata Transaction e che può essercene più di una, allora di nuovo non hai un'implementazione molto vivace del dominio aziendale. Ad esempio, SavingsAccount dovrebbe forse sapere che non può accettare una DebitTransaction se accountStatus è chiuso. Molte implementazioni lo lascerebbero al manager.

Avere molte classi "manager" è spesso un sintomo di un modello di dominio anemico , in cui la logica di dominio viene sollevata dal modello di dominio e invece collocata in classi manager, che più o meno equivalgono a script di transazione . Il pericolo qui è che stai sostanzialmente tornando alla programmazione procedurale - che di per sé potrebbe o meno essere una buona cosa a seconda del tuo progetto - ma il fatto che non sia stato considerato o inteso è il "odore di codice" imo.

Seguendo il principio dell ' "esperto di informazioni" , un'operazione logica dovrebbe risiedere il più vicino possibile ai dati richiesti. Ciò significherebbe riportare la logica di dominio nel modello di dominio, in modo che siano queste operazioni logiche che hanno un effetto osservabile sullo stato del modello di dominio, piuttosto che script di transazione che cambiano lo stato del modello di dominio dall'esterno.

Il problema più grande con le Classi Manager è che rappresentano solo questa vaga idea di cosa dovrebbe fare la classe. Se chiami qualcosa un Manager, allora può fare qualsiasi cosa possibile in relazione a ciò che sta gestendo. Suppongo che in alcuni contesti potrebbe essere ok, ma direi in quasi tutti i casi che non è quello che vuoi. Vuoi che qualcuno sia in grado di guardare il nome della classe e non solo avere una buona idea di ciò che fa la classe, ma anche di ciò che non fa.

Un altro problema con le classi manager è che rende molto difficile decidere dove dovrebbe andare la funzionalità. Quando ci sono molte classi manager, allora spesso ci sono molte sovrapposizioni di funzionalità tra le classi manager. Devi quindi capire quale classe dovrebbe implementare quella funzionalità sovrapposta e, naturalmente, qualcun altro avrebbe scelto diversamente. Quindi, quando cercano la funzionalità e non la vedono dove si aspettano, vanno avanti e la implementano dove pensano che appartengano perché non sono consapevoli dell'esistenza dell'altra implementazione. In altre parole, le classi manageriali portano a progetti difficili da capire e spesso contorti.