Come evitare di scrivere classi Manager?

Mi sembra di continuare a leggere che è una cattiva idea usare le XxxManagerclassi di stile nella programmazione del motore di gioco, ma anche quando provo ad evitarne l'uso finisco sempre con qualcosa che contiene tutti gli attori / entità / posizioni del mondo di gioco e agisce su di loro, che finisce per essere un Managerif con un altro nome.

È davvero un cattivo modello da seguire? In tal caso, quali sono le alternative?

Le classi "Manager" possono essere problematiche per vari motivi. I due motivi principali tendono ad essere:

• il nome non è chiaro (cosa comporta in realtà "gestione", ed è sempre lo stesso per ogni tipo di cosa gestita?)
• tendono ad essere secchi di funzionalità che violano il principio della singola responsabilità (cioè che un tipo dovrebbe fare una cosa)

Spesso uno di questi motivi causa o implica l'altro.

Questi problemi sono buoni aspetti da tenere a mente, ma non lasciare che paralizzino la tua capacità di realizzare il tuo gioco . Alla fine nessuno si preoccuperà di come si chiamano le tue lezioni o di cosa fanno. Si occuperanno del tuo gioco.

Di solito è abbastanza facile separare la maggior parte dei "gestori" in due parti:

• la parte che memorizza gli oggetti reali e fornisce l'accesso ad essi (che è possibile chiamare un "archivio", un "repository", un "database", "una cache" o varie altre cose. Questo è il tipo di solito responsabile per la durata degli oggetti, ovvero quando un oggetto viene rimosso da o altrimenti non è più contenuto da un'istanza di questo tipo, cessa di esistere.

• la parte che elabora gli oggetti reali ed esegue alcuni lavori su di essi. Potrebbe aggiornare quegli oggetti (quindi è un "programma di aggiornamento" o "simulazione") o potrebbe disegnarli (quindi è un "cassetto" o "renderer"). Oppure potrebbe fare qualcos'altro con loro; l'importante è nominarlo in base al suo scopo principale. Generalmente darei alle istanze di questo tipo un'istanza o un riferimento alle istanze del primo tipo (quella che gestisce solo la durata degli oggetti).

Si potrebbe sostenere che il nome del primo tipo potrebbe includere manager (poiché "gestisce la durata di" alcuni oggetti). Il mondo non finirà se nominerai così il tuo tipo, anche se potresti dover sopportare reazioni istintive del modulo "non chiamare gestori di cose" piuttosto spesso, quindi potresti volerlo evitare solo per quello.

Quando leggi il post sul blog a cui ti sei collegato nei commenti, vedrai che "essere un Manager se con un altro nome" è esattamente ciò che vuole che tu faccia. È opinione generale nello sviluppo del software che le variabili globali siano malvagie e l'unica alternativa è che qualsiasi dato è detenuto da altri dati.

Il problema con una classe denominata FoobarManagerè che la parola "Manager" non ti dice cosa fa effettivamente la classe . Per esempio:

• Quando controlla la meccanica di gioco dei foobar, puoi nominarlo FoobarController.
• Quando crea un'istanza di foobar ma poi delega il controllo a qualcos'altro, è un FoobarFactoryo FoobarBuilder.
• Quando attira i foobar sullo schermo, è a FoobarRenderer.
• Quando ascolta gli eventi generati dai foobar, è a FoobarEventHandler.
• Quando aspetta che accada qualcosa con i foobar, è un FoobarObserver.
• Quando si tratta solo di un muto detentore di dati per una raccolta di foobar senza alcuna logica, basta nominarlo Foobars.

Puoi nominare una di queste classi "Manager". Ma poi potrebbe eseguire una di queste funzionalità. E quando in seguito ti renderai conto di aver bisogno di un'altra delle funzionalità di cui sopra, la integrerai anche nel FoobarManager. Quindi finirai con un oggetto dio che rompe il principio di separazione delle preoccupazioni (ogni classe dovrebbe fare esattamente una cosa).