Que devrions-nous utiliser à la place d'une classe "manager" dans une bonne conception POO?

Question

Je vais avoir de la difficulté à la conception de mon moteur de jeu. Par exemple:

Quand je pense que dans les Ressources, je pense que dans une classe ResourceManager classe pour gérer les ressources sur mon moteur.

Cette classe devient plusieurs responsabilités:

• Chargement des ressources.
• Carte des ressources par un identificateur.
• S'assurer que les ressources sont chargés qu'une seule fois.
• Gratuit des ressources non utilisées (à l'aide de smartpointers).

Cela fonctionne pour moi, mais j'ai lu sur tous les OOP conception tutoriel que les gestionnaires sont ambigus classes avec des haut de couplage et de faible cohésion. Je comprends cela, et je suis d'accord, mais j'ai cherché presque l'ensemble de l'Internet pour trouver un exemple clair d'une véritable alternative pour les Gestionnaires, mais je n'ai pas trouvé.

Certaines personnes expliquent, par exemple, que ResourceManager devrait être divisé en plus petites classes: Une ResourceFactory, un ResourceCollection, un ResourceCache, un ResourceFacade...

Je sais tous ces modèles de conception de l'Usine, de Collecte, de Façade, etc.) Mais je n'ai pas vraiment compris comment cela peut être joint à créer une (plus facile à gérer) système de gestion des ressources.

Ma question est: Est-il un tutoriel ou un document avec un exemple clair? Quelqu'un peut m'expliquer un exemple de ce système? Je vais je vous remercie si vous pouvez écrire un petit exemple en C++ ou autre langage.

Merci d'avance pour votre aide!

Answer 1

Vous avez presque dit qu'il a déjà:

Cette classe devient plusieurs responsabilités

(original accent).

Cela viole le Principe de Responsabilité Unique. En outre, le mot du Gestionnaire de proposer un objet qui gère d'autres objets, ce qui est en contradiction avec l'orienté objet principe que les objets doivent encapsuler à la fois les données et le comportement. Cela conduit rapidement à la Fonction de l'Envie du code de l'odorat.

La division de la gestionnaire en plusieurs petites classes est la bonne chose à faire. Pour les contrôler, vous pouvez mettre en œuvre une Façade au-dessus d'eux.

Answer 2

Peut-être:

• Charger des ressources -> ResourceLoader
• Carte des ressources par un identifiant -> ResourceMapper
• S'assurer que les ressources sont chargées une seule fois -> CachedResourceLoader / celui-ci utilise l' ResourceLoader quand il n'est pas déjà chargé
• Gratuit des ressources non utilisées (à l'aide de smartpointers) -> ? / pas sûr à ce sujet, mais de chargement+déchargement semble très cohérent de concepts

---

re plus d'info dans le commentaire à propos de "Free des ressources non utilisées":

Tout d'abord, disons-le clairement que nous n'avons que 2 ci-dessus impliqués: ResourceMapper et CachedResourceLoader. Comme le ResourceLoader exemple, est utilisé à partir de la CachedResource, il n'est pas exposé au reste du code.

Notez que celui-ci dépend de la connaissance du domaine, donc je vais le garder ouvert / vous saurez lequel de ces sens s'applique à des pièces que vous avez. Je dirais il y a 3 possibilités:

• ResourceMapper utilise CachedResourceLoader, et de vous exposer uniquement au plus tôt pour le reste du code.
  • Dans cette approche, il y a un point d'entrée unique à travers ResourceMapper, il est donc logique qu'il contrôle FreeUnused().
  • Une fois qu'il détermine, il peut libérer une ressource, il va le supprimer de la carte. Si besoin, il appelle un Déchargement pour des éléments spécifiques à la CachedResourceLoader
• Les deux CachedResourceLoader et ResourceMapper sont utilisés par l'appelant.
  • Si vous avez seulement besoin de FreeUnused de la ResourceMapper, puis il suffit de l'ajouter là.
  • Si elle a besoin d'être libérée à partir de deux, l'un de:
  • .FreeUnused dans le ResourceMapper reçoit un cachedResourceLoader. Après la détermination de/enlever les éléments de la carte, il passe à la liste des ressources gratuites de la cachedResourceLoader exemple
  • .FreeUnused dans le ResourceMapper retourne la liste des ressources libérées à partir de la carte. L'appelant appels .Décharger sur le cachedResourceLoader en passant la liste des ressources à Décharger. Peut-être que vous avez une belle place en l'appelant ces 2 appels irait bien.
• Vous utilisez une classe ResourceManager, mais au lieu d'avoir toutes les implémentations de là, il utilise le ResourceMapper et CachedResourceLoader. Ce serait très mince, il suffit de faire des appels vers les autres, en particulier de la .FreeUnused et .Décharger les appels dans la dernière sous-puce ci-dessus.

Une dernière remarque: je pense que cela vaut vraiment la peine de séparer les responsabilités et de se sentir forte à propos de le faire. Cela dit, c'est du SOLIDE des principes que j'ai suivi la plupart, je ne mémorise pas de motif de noms et de ne pas payer beaucoup d'attention à des règles comme Gestionnaire de classes sont mauvais.

Answer 3

Mais je ne pense pas qu'il y a forcément quelque chose de mal avec votre solution. À mon humble avis, si vous pensez que sur des choses que vous avez dit de la Programmation Orientée Aspectspoint de vue, c'est juste un aspect de vos ressources, qui sera traitée par votre classe.

Bien que si vous pensez que dans les grandes et votre base de code peut évolué dans des centaines de ligne de code, il sera mieux pour abattre vos fonctions d'Infrastructure(Domain Driven Design Patterns).

Je pense que votre classe est la cohésion, l'un et le nom du gestionnaire n'est pas toujours un mauvais signe, sauf qu'elle consolide le flux de contrôle de nombreux éventuellement sans rapport avec les classes qui collaborent les uns avec les autres pour accomplir une tâche.

J'ai fait un commentaire que si vos exigences sur la mise en cache et de la cartographie est sujette à changement peut-être il serait mieux de Séparer vos Préoccupations.

Answer 4

Vous n'avez pas besoin d'être dogmatique sur les modèles de conception ou d'une architecture particulière. Juste faire quelque chose de document et de bien.

En d'autres termes, la décomposition d'une classe en plus petites classes, parce que la plus grande classe a de multiples responsabilités est un bon principe, mais pas un droit. Vous ne voulez pas suivre à tout prix. Regardez les avantages et les inconvénients de l'appliquer. Parfois, la décomposition d'une classe en plus petites classes vous donne plus de contrôle sur responsaibilities, mais au détriment d'une grande partie de la communication entre les classes. Dans votre exemple, vous pourriez aussi bien mettre en œuvre les différentes classes de chargement des ressources, la mise en cache, de cartographie, d'économie, etc. Mais si chaque classe a besoin de parler pour les autres en vue de l'exécution de ses travaux, puis la décomposition n'est pas la peine de le faire, parce qu'elle entraîne haut de couplage, ce qui est mauvais; de garder le tout dans une seule classe.

Parfois, je pense que les modèles de conception ont provoqué autant de dégâts que la clarté du logiciel de développement monde! :-)

Answer 5

Je sais tous ces modèles de conception de l'Usine, de Collecte, de Façade, etc.) Mais je n'ai pas vraiment compris comment cela peut être joint à créer une (plus facile à gérer) système de gestion des ressources.

Qui dit qu'ils devraient être réunis? Alors vous êtes de retour où vous avez commencé, n'est-ce pas? Tout le point de rompre le gestionnaire de classes, c'est que vous vous retrouvez avec plusieurs éléments plus simples. Si vous avez besoin des fonctionnalités de mise en cache, vous parlez à la cache. Si vous avez besoin de la ressource fonctionnalité de chargement vous parler pour le chargeur de ressources.