Un groupe d'amis et moi travaillons depuis peu sur un projet, et nous voulions inventer une belle façon OOP de représenter un scénario spécifique à notre produit. Fondamentalement, nous travaillons sur un jeu d'enfer de balle de style Touhou , et nous voulions créer un système où nous pourrions facilement représenter tout comportement possible de balle que nous pourrions imaginer.
C'est exactement ce que nous avons fait; nous avons fait une architecture vraiment élégante qui nous a permis de séparer le comportement d'une balle en différents composants qui pourraient être attachés aux instances de balle à volonté, un peu comme le système de composants d'Unity . Il fonctionnait bien, il était facilement extensible, il était flexible et couvrait toutes nos bases, mais il y avait un léger problème.
Notre application implique également une grande quantité de génération de procédures, à savoir que nous générons de manière procédurale les comportements des balles. Pourquoi c'est un problème? Eh bien, notre solution de POO pour représenter le comportement des balles, tout en étant élégante, est un peu compliquée à travailler sans être humain. Les humains sont suffisamment intelligents pour penser à des solutions à des problèmes à la fois logiques et intelligents. Les algorithmes de génération procédurale ne sont pas encore aussi intelligents, et nous avons eu du mal à implémenter une IA qui utilise notre architecture OOP à son plein potentiel. Certes, c'est une faille de l'architecture, c'est qu'elle n'est pas intuitive dans toutes les situations.
Donc, pour remédier à ce problème, nous avons essentiellement poussé tous les comportements offerts par différents composants dans la classe de puce, de sorte que tout ce que nous pouvions imaginer soit proposé directement dans chaque instance de puce, par opposition à dans d'autres instances de composants associées. Cela rend nos algorithmes de génération procédurale un peu plus faciles à utiliser, mais maintenant notre classe bullet est un énorme objet divin . C'est de loin la classe la plus importante du programme avec plus de cinq fois plus de code qu'autre chose. C'est aussi un peu pénible à maintenir.
Est-il normal qu'une de nos classes se transforme en objet divin, juste pour faciliter le travail avec un autre problème? En général, est-il acceptable d'avoir des odeurs de code dans votre code s'il admet une solution plus facile à un problème différent?