Le classi manager possono essere un segno di cattiva architettura?

Le classi Manager possono essere un segno di una cattiva architettura, per alcuni motivi:

• Identificatori senza significato

  Il nome FooManager non dice nulla su ciò che la classe effettivamente , tranne che in qualche modo coinvolge Foo istanze. Dare alla classe un nome più significativo chiarisce il suo vero scopo, che probabilmente porterà al refactoring.

• Responsabilità frazionali

  Secondo il principio della responsabilità unica, ogni unità di codice dovrebbe servire esattamente a uno scopo. Con un manager, potresti dividere artificialmente questa responsabilità.

  Considera un ResourceManager che coordina le durate di e l'accesso alle istanze Resource . Un'applicazione ha un singolo ResourceManager attraverso il quale acquisisce Resource istanze. In questo caso non c'è una vera ragione per cui la funzione di un'istanza ResourceManager non può essere servita da metodi statici nella classe Resource .

• Astrazione non strutturata

  Spesso viene introdotto un manager per astrarre i problemi sottostanti con gli oggetti che gestisce. Questo è il motivo per cui i manager si prestano ad abusare come cerotti per sistemi mal progettati. L'astrazione è un buon modo per semplificare un sistema complesso, ma il nome "manager" non offre alcun indizio sulla struttura dell'astrazione che rappresenta. È davvero una fabbrica, un proxy o qualcos'altro?

Ovviamente, i manager possono essere usati non solo per il male, per le stesse ragioni. Un EventManager , che è in realtà un Dispatcher , inserisce gli eventi dalle origini e li invia agli obiettivi interessati. In questo caso ha senso separare la responsabilità di ricevere e inviare eventi, perché un singolo Event è solo un messaggio senza nozioni di provenienza o destinazione.

Scriviamo un Dispatcher di Event istanze essenzialmente per lo stesso motivo in cui scriviamo GarbageCollector o Factory :

Un manager sa quale sia il suo carico utile da non conoscere.

Questa, penso, è la migliore giustificazione per creare una classe manageriale. Quando si dispone di un oggetto "payload" che si comporta come un valore, dovrebbe essere il più stupido possibile in modo che il sistema generale rimanga flessibile. Per fornire un significato alle singole istanze, si crea un gestore che coordina quelle istanze in modo significativo. In qualsiasi altra situazione, i gestori non sono necessari.

I manager possono essere un segno di una cattiva architettura, ma il più delle volte sono solo un segno di incapacità da parte del progettista di trovare nomi migliori per i suoi oggetti, o semplicemente solo una riflessione sul fatto che la lingua inglese (e qualsiasi altra lingua umana per quella materia) è adatta per comunicare concetti pratici quotidiani, e non concetti altamente astratti e altamente tecnici.

Un semplice esempio per illustrare il mio punto: prima che il Pattern di fabbrica fosse nominato, le persone lo stavano usando, ma non sapevano come chiamarlo. Quindi, qualcuno che ha dovuto scrivere una factory per la sua classe Foo potrebbe averlo chiamato FooAllocationManager . Non è un cattivo design, è solo mancanza di immaginazione.

E poi qualcuno deve implementare una classe che mantenga molte fabbriche e le distribuisca a vari oggetti che le richiedono; e chiama la sua classe FactoryManager perché la parola Industry non gli è mai venuta in mente, o ha pensato che non sarebbe stato un buon livello perché non aveva mai sentito parlare di qualcosa di simile nella programmazione. Di nuovo, un caso di mancanza di immaginazione.

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 vero problema imo.

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 spostare 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 "gestori" che modificano lo stato del modello di dominio dall'esterno.

Risposta breve: dipende .

Esistono diverse forme di "classi di manager", alcune sono buone, altre sono cattive e per la maggior parte di esse dipende molto dal contesto se l'introduzione di una classe manager è la cosa giusta. Un buon punto di partenza per farli bene è seguire il principio di responsabilità singola - se sai esattamente quale sia la tua classe manageriale è responsabile di (e cosa no), avrai meno problemi a comprenderli.

O per rispondere direttamente alla tua domanda: non è il numero di classi di manager che indicano una cattiva architettura, ma ne hanno troppe con responsabilità poco chiare o troppe preoccupazioni.

Anche se potrebbe essere facile dire che sono intrinsecamente indicativi di un cattivo design, possono servire a portare molto bene e ridurre la complessità del codice e altri codici standard nel progetto includendo un singolo compito e responsabilità universalmente.

Sebbene la prevalenza dei Manager possa essere dovuta a un giudizio insoddisfacente sulla progettazione, potrebbe anche essere la gestione delle decisioni di progettazione scadenti o problemi di incompatibilità con altri componenti in una progettazione componentistica o componenti dell'interfaccia utente di terze parti o servizi web di terze parti con una strana interfaccia come esempi.

Questi esempi dimostrano dove sono terribilmente utili in certe situazioni per ridurre la complessità complessiva e promuovere l'accoppiamento libero tra vari componenti e livelli incapsulando il "codice brutto" in un unico posto. Tuttavia, è probabile che le persone trovino la tentazione di rendere i manager come single singleton, vorrei sconsigliarlo, e ovviamente come altri hanno suggerito che il principio di responsabilità unica debba essere sempre seguito.

Can manager classes be a sign of bad architecture?

Hai risposto alla tua domanda: non devono essere un segno di cattivo design.

Tranne l'esempio nella tua domanda con EventManager, c'è un altro esempio: nel MVC design pattern, il presenter può essere visto come un gestore per le classi model / view.

Tuttavia, se usi male un concetto, allora è un segno di una cattiva progettazione e forse di un'architettura.

Quando la classe ha "Manager" nel nome, fai attenzione al dio class problema (uno con troppe responsabilità). Se è difficile descrivere con che nome è responsabile una classe, si tratta di un segno di avvertenza di progettazione.

A parte le cattive lezioni di manager, il nome peggiore che abbia mai visto era "DataContainerAdapter"

"I dati" dovrebbe essere un'altra di quelle sottostringhe vietate nei nomi: sono tutti dati, i "dati" non ti dicono molto nella maggior parte dei domini.

Classi di manager - proprio come quasi qualsiasi classe che termina con "-er" - sono cattivi e non hanno nulla a che fare con OOP. Quindi per me è un segno di cattiva architettura.

Perché? Il nome "-er" implica che un progettista del codice ha preso qualche azione e lo ha convertito in classe. Di conseguenza abbiamo un'entità artificiale che non riflette alcun concetto tangibile, ma qualche azione. Sembra molto procedurale.

Oltre a ciò, in genere tali classi prendono alcuni dati e operano su di essi. Questa è una filosofia di dati passivi e procedure attive e ha trovato il suo posto nella programmazione procedurale. Se lo realizzi, non c'è niente di male nelle classi Manager, ma non è OOP allora.

Il pensiero degli oggetti implica che gli oggetti fanno cose a se stessi. Scopri il tuo dominio , crea reti semantiche , lascia che i tuoi oggetti siano organismi viventi, umani intelligenti e responsabili.

Tali oggetti non hanno bisogno di essere controllati. Sanno cosa fare e come fare. Quindi le lezioni di Manager infrangono i principi OOP due volte. Oltre ad essere una classe "-er", controlla altri oggetti. Ma dipende comunque dal manager. Controlla - è un cattivo manager. Se coordina - è un buon manager. Ecco perché una lettera "C" in MVC deve essere scritta come "Coordinatore" .

La risposta corretta a questa domanda è:

1. Dipende.

Ogni situazione che incontrerai durante la scrittura del software è diversa. Forse sei in una squadra in cui tutti sanno come funzionano le classi di manager internamente? Sarebbe completamente pazzo non usare quel disegno. O se stai cercando di spingere il manager-design ad altre persone, nel qual caso potrebbe essere una cattiva idea. Ma dipende da dettagli precisi.