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

Ci sono forse due motivi per cui questo è un odore di codice. Una ragione è che potrebbe significare che non si hanno oggetti di dominio ma invece si hanno oggetti di valore che conservano solo i dati per la manipolazione da parte delle classi del controllore o del gestore. Questo è in realtà piuttosto comune ed equivale alla programmazione procedurale in un linguaggio OO. I "molti manager" possono essere un indizio del fatto che è necessario integrare la logica di stato, la convalida e altre preoccupazioni dirette negli oggetti del dominio in modo che in realtà incapsulino qualcosa. Naturalmente ci sono suggerimenti più importanti come il fatto che non ci sono metodi diversi da getter / setter.

L'altro motivo per cui il suo odore di codice è che potrebbe significare che gli oggetti del tuo dominio non si correlano molto bene tra loro. Ad esempio se hai una classe Account che in realtà non sa nulla della classe Transaction eccetto che si chiama Transaction e che ce ne possono essere più di una, allora ancora una volta non hai un'implementazione molto dinamica del dominio aziendale. Ad esempio, SavingsAccount dovrebbe sapere che non può accettare un DebitTransaction se accountStatus è chiuso. Molte implementazioni lascerebbero questo al gestore.

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

Seguendo il principio del "esperto di informazioni" , un'operazione logica dovrebbe risiedere il più vicino possibile ai dati che richiede il più possibile. 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 gli script di transazione che cambiano lo stato del modello di dominio dall'esterno.

Il problema più grande con Manager Classes è che rappresentano solo questa vaga idea di ciò che la classe dovrebbe fare. Se chiami qualcosa come Manager, può fare qualsiasi cosa e ogni cosa possibile in relazione a qualsiasi cosa stia gestendo. Suppongo che in alcuni contesti potrebbe essere ok, ma in quasi tutti i casi direi 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 cosa fa la classe ma anche cosa non fa.

Un altro problema con le classi manager è che rende molto difficile decidere dove dovrebbe andare la funzionalità. Quando ci sono molte classi di manager, spesso c'è molta sovrapposizione di funzionalità tra le classi manager. Devi quindi capire quale classe dovrebbe implementare quella funzionalità sovrapposta e, naturalmente, qualcun altro avrebbe scelto in modo diverso. Quindi, quando cercano la funzionalità e non la vedono dove si aspettano, vanno avanti e la re-implementano dove pensano che appartenga perché non sono a conoscenza dell'esistenza dell'altro. In altre parole, le classi di manager portano a progetti difficili da comprendere e spesso contorti.