Comment éviter d'écrire des cours Manager?

Je semble continuer à lire que c'est une mauvaise idée d'utiliser XxxManagerdes classes de style dans la programmation du moteur de jeu, mais même lorsque j'essaie d'éviter leur utilisation, je me retrouve toujours avec quelque chose qui contient tous les acteurs / entités / emplacements du monde du jeu et agit sur eux, ce qui finit par être un Managersi sous un autre nom.

Est-ce vraiment un mauvais schéma à suivre? Si oui, quelles sont les alternatives?

Les classes "Manager" peuvent être problématiques pour diverses raisons. Les deux principales raisons ont tendance à être:

• le nom n'est pas clair (qu'implique réellement la "gestion", et est-ce toujours le même pour chaque type de chose gérée?)
• ils tendent à être des ensembles de fonctionnalités qui violent le principe de responsabilité unique (c'est-à-dire qu'un type doit faire une chose)

Souvent, l'une de ces raisons cause ou implique l'autre.

Ces problèmes sont de bonnes choses à garder à l'esprit, mais ne les laissent pas paralyser votre capacité à réellement créer votre jeu . En fin de compte, personne ne se souciera du nom de vos cours ou de ce qu'ils font. Ils vont se soucier de votre jeu.

Il est généralement assez facile de séparer la plupart des "managers" en deux parties:

• la partie qui stocke les objets réels et leur donne accès (que vous pouvez appeler un «magasin», un «référentiel», une «base de données», un «cache» ou diverses autres choses. C'est le type qui est généralement responsable pour la durée de vie des objets, c'est-à-dire lorsqu'un objet est supprimé d'une autre instance de ce type ou n'est plus contenu par lui, il cesse d'exister.

• la partie qui traite les objets réels et effectue certains travaux sur eux. Il peut mettre à jour ces objets (alors c'est un "programme de mise à jour" ou "simulation") ou il peut les dessiner (alors c'est un "tiroir" ou "rendu"). Ou il pourrait faire autre chose avec eux; l'important est de le nommer selon son objectif principal. Vous donneriez généralement aux instances de ce type une instance ou une référence aux instances du premier type (celle qui gère uniquement la durée de vie des objets).

Un argument raisonnable pourrait être avancé selon lequel le nom du premier type pourrait inclure gestionnaire (car il "gère la durée de vie" de certains objets). Le monde ne se terminera pas si vous nommez votre type ainsi, bien que vous ayez peut-être à supporter des réactions instinctives du type "n'appelez pas les gestionnaires de choses" assez souvent, vous voudrez donc peut-être l'éviter juste pour cela.

Lorsque vous lisez le billet de blog auquel vous avez lié dans les commentaires, vous verrez que "être un gestionnaire si sous un autre nom" est exactement ce qu'il veut que vous fassiez. Il est généralement admis dans le développement de logiciels que les variables globales sont mauvaises, et la seule alternative est que toutes les données soient détenues par d'autres données.

Le problème avec une classe nommée FoobarManagerest que le mot "Manager" ne vous dit pas ce que fait réellement la classe . Par exemple:

• Lorsqu'il contrôle les mécanismes de jeu des foobars, vous pouvez le nommer FoobarController.
• Quand il instancie les foobars mais délègue ensuite le contrôle à autre chose, c'est un FoobarFactoryou FoobarBuilder.
• Quand il attire les foobars à l'écran, c'est un FoobarRenderer.
• Quand il écoute les événements générés par les foobars, c'est a FoobarEventHandler.
• Quand il attend que quelque chose se passe avec les foobars, c'est a FoobarObserver.
• Quand il s'agit simplement d'un support de données stupide pour une collection de foobars sans aucune logique, il suffit de le nommer Foobars.

Vous pouvez nommer n'importe laquelle de ces classes "Manager". Mais il pourrait alors exécuter n'importe laquelle de ces fonctionnalités. Et lorsque vous réaliserez plus tard que vous avez besoin d'une autre des fonctionnalités ci-dessus, vous l'intégrerez également dans le FoobarManager. Vous vous retrouverez donc avec un objet divin qui brise le principe de séparation des préoccupations (chaque classe doit faire exactement une chose).