OO Design - Objet demande une question à la classe qui le détient indirectement

Question

Je me demande si un objet posant une question à un autre objet qui le détient indirectement est un "mauvais" design. Par exemple ...

Exigences: Caractère (un objet) se déplace sur une grille. Quand il essaie de se déplacer vers un autre point, il doit savoir si ce point est déjà occupé par quelque chose qui le bloque, ou si cette partie de la grille est complètement inaccessible. (Notez que le personnage lui-même a besoin de savoir).

Dans l'application, un état contient un gestionnaire d'images et un gestionnaire de caractères. Le tilemanager sait quelles tuiles sont accessibles et lesquelles ne le sont pas. Le gestionnaire de caractères connaît les emplacements des tuiles des personnages. Est-ce que le caractère peut appeler une fonction à partir de l'état, par exemple AuthorizeMovement, qui détermine si le déplacement est possible via TileManager et CharacterManager, et renvoie true si oui, false sinon?

Est-ce que cela enfreint des principes importants, ce qui entraîne des problèmes sur la route?

Évidemment, ceci est généralisé et réduit à ce qui est nécessaire pour comprendre le problème.

Answer 1

Je ne vois pas de problème. Good OO Design est livré avec de nombreux principes. Mais à la base, vous avez le grand 4: Encapsulation, Héritage, Polymorphisme et Abstraction. En outre, vous souhaitez une cohésion élevée et un faible couplage. Cela signifie que vos objets/classes peuvent s'adapter n'importe où et ne sont pas liés à une implémentation ou une classe particulière. Cela dit, il semble que vous ayez utilisé ce qui précède pour un mouvement encapsulé et que les caractères les séparent en classes séparées. Donc votre classe de personnage ne modifie pas directement le tableau, ce qui serait mauvais si c'était le cas. Au fur et à mesure que vous comprenez mieux votre problème, vous pouvez toujours refactoriser votre code pour améliorer votre conception afin de tirer parti d'autres principes.

Answer 2

Je dirais que c'est probablement un mauvais design, oui. Le «drapeau rouge», pour ainsi dire, est la référence circulaire. Vous avez dit:

... un objet de poser une question à un autre objet qui détient indirectement

Ainsi, la « holding » objet a une référence à l'objet « occupé », et aussi Afin de «poser une question», l'objet «tenu» aura besoin d'une référence à l'objet «tenant».

Cela crée un graphique de dépendance d'objet circulaire et est souvent une odeur de code.

Il semblerait qu'une autre classe devrait avoir la responsabilité de connaître à la fois le personnage et le TileManager et/ou le CharacterManager.

Answer 3

Ce n'est pas contre le principe de la POO. Les détails de l'appel sont totalement abstraits et vous dépendez de l'objet State de toute façon. Comment diable pourriez-vous mettre en œuvre cette fonction?

L'abstraction et les principes sont des outils utiles. Mais vous ne devriez pas dépendre d'eux pour qualifier votre code comme bon. Toutes les abstractions ou tous les principes ne sont pas bons pour tous les scénarios ou toutes les implémentations possibles. Ce sont des lignes directrices, pas des règles. Si vous ne pouvez pas voir rapidement une implémentation alternative, utilisez celle-ci, puis revenez-y.