Le classi manageriali possono essere un segno di cattiva architettura?

Ultimamente ho iniziato a pensare che avere molte classi manageriali nel tuo design sia una cosa negativa. L'idea non è maturata abbastanza per farmi un argomento convincente, ma ecco alcuni punti generali:

• Ho scoperto che è molto più difficile per me capire i sistemi che dipendono fortemente dai "gestori". Questo perché, oltre agli attuali componenti del programma, devi anche capire come e perché viene utilizzato il gestore.

• I manager, per la maggior parte del tempo, sembrano essere usati per alleviare un problema con la progettazione, come quando il programmatore non riusciva a trovare un modo per rendere il programma Just Work ^TM e doveva fare affidamento sulle classi manager per far funzionare tutto correttamente.

Certo, i mangiatori possono essere buoni. Un esempio ovvio è EventManageruno dei miei costrutti preferiti di tutti i tempi. : P Il mio punto è che i manager sembrano essere abusati per la maggior parte del tempo, e per nessuna buona ragione se non mascherare un problema con l'architettura del programma.

Le classi manageriali sono davvero un segno di cattiva architettura?

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

• Identificatori insignificanti

  Il nome FooManagernon dice nulla su ciò che la classe effettivamente fa , tranne per il fatto che in qualche modo coinvolge Fooistanze. Dare alla classe un nome più significativo chiarisce il suo vero scopo, che probabilmente porterà al refactoring.

• Responsabilità frazionarie

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

  Si consideri un elemento ResourceManagerche coordina la durata e l'accesso alle Resourceistanze. Un'applicazione ha un singolo ResourceManagertramite il quale acquisisce Resourceistanze. In questo caso non esiste alcun motivo reale per cui la funzione di ResourceManagerun'istanza non possa essere servita da metodi statici nella Resourceclasse.

• Astrazione non strutturata

  Spesso viene introdotto un manager per sottrarre i problemi sottostanti agli oggetti che gestisce. Questo è il motivo per cui i manager si prestano ad abusare come ausili alla banda 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?

Certo, i manager possono essere usati per qualcosa di più del semplice male, per le stesse ragioni. Un EventManager— che è veramente un Dispatcher—queues eventi da fonti e li invia a obiettivi interessati. In questo caso ha senso separare la responsabilità di ricevere e inviare eventi, perché un individuo Eventè solo un messaggio senza nozione di provenienza o destinazione.

Scriviamo una Dispatcherdelle Eventistanze essenzialmente per lo stesso motivo per cui scriviamo una GarbageCollectoro una Factory:

Un manager sa cosa non dovrebbe sapere il suo payload.

Questa, penso, sia la migliore giustificazione che ci sia per creare una classe manageriale. Quando hai 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 significato alle singole istanze, si crea un gestore che coordina tali 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 inventare nomi migliori per i suoi oggetti, o semplicemente un riflesso del fatto che la lingua inglese (e qualsiasi linguaggio umano per quella materia) è adatto per comunicare concetti pratici di ogni giorno e concetti non altamente astratti, altamente tecnici.

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

E poi qualcuno ha bisogno di implementare una classe che mantiene molte fabbriche e le distribuisce a vari oggetti che le richiedono; e chiama la sua classe FactoryManagerperché la parola Industrynon gli è mai venuta in mente, o pensava che sarebbe stato poco piacevole perché non aveva mai sentito parlare di qualcosa del genere in programmazione. Ancora una volta, un caso di mancanza di immaginazione.

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 preso in considerazione o previsto è il vero problema 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 i "gestori" cambiano lo stato del modello di dominio dall'esterno.

Risposta breve: dipende .

Esistono diverse forme distinte di "classi manager", alcune sono buone, altre cattive e per la maggior parte dipende molto dal contesto se l'introduzione di una classe manager è la cosa giusta. Un buon punto di partenza per ottenerli giusti è seguire il principio della responsabilità singola : se sai esattamente di cosa è responsabile (e cosa no) ciascuna classe dirigente, avrai meno problemi a comprenderli.

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

Mentre potrebbe essere facile dire che sono intrinsecamente indicativi di una cattiva progettazione, possono servire a portare molto bene e ridurre la complessità del codice e altri codici della caldaia in tutto il progetto comprendendo una singola attività e responsabilità universalmente.

Sebbene la prevalenza dei manager possa essere dovuta a un giudizio inadeguato sulla progettazione, possono anche essere per gestire le decisioni di progettazione scadenti o i problemi di incompatibilità con altri componenti in un design componente 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 per determinate situazioni nel ridurre la complessità generale e nel promuovere un accoppiamento libero tra vari componenti e livelli incapsulando il "codice brutto" in un unico posto. Tuttavia, una cosa sarebbe che le persone trovino la tentazione di fare dei manager come singoli, io sconsiglierei questo, e naturalmente come altri hanno suggerito che il principio della responsabilità singola dovrebbe essere sempre seguito.

Le classi manageriali possono essere un segno di cattiva architettura?

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

Tranne l'esempio nella tua domanda con EventManager, c'è un altro esempio: nel modello di progettazione MVC , il presentatore può essere visto come un gestore per le classi modello / vista.

Tuttavia, se si fa un uso improprio di un concetto, allora è un segno di un cattivo design e forse di un'architettura.

Quando la classe ha "Manager" nel nome, fai attenzione al problema della classe divina (uno con troppe responsabilità). Se è difficile descrivere ciò che una classe è responsabile con il suo nome, questo è un segnale di avvertimento di progettazione.

A parte le cattive classi di manager, il peggior nome che abbia mai visto è stato "DataContainerAdapter"

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

Le classi manager - proprio come quasi tutte le classi che terminano con "-er" - sono malvagie 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 di codice ha intrapreso alcune azioni e lo ha convertito in classe. Di conseguenza abbiamo un'entità artificiale che non riflette alcun concetto tangibile, ma un'azione. Sembra molto procedurale.

Oltre a ciò, in genere tali classi raccolgono alcuni dati e vi operano. Questa è una filosofia di dati passivi e procedure attive e ha trovato il suo posto nella programmazione procedurale. Se te ne rendi conto, non c'è niente di male nelle classi Manager, ma non è OOP allora.

Il pensiero oggettivo implica che gli oggetti fanno le cose da soli. Scopri il tuo dominio , costruisci reti semantiche , lascia che i tuoi oggetti siano organismi viventi, esseri umani intelligenti e responsabili.

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

La risposta corretta a questa domanda è:

1. Dipende.

Ogni situazione che incontrerai durante la scrittura del software è diversa. Forse fai parte di un team in cui tutti sanno come funzionano internamente le classi manageriali? Sarebbe del tutto folle non usare quel design. O se stai cercando di spingere il design manager ad altre persone, nel qual caso potrebbe essere una cattiva idea. Ma dipende da dettagli esatti.