J'y réfléchis depuis des jours et je ne sais toujours pas quoi faire. J'essaie de refactoriser un système de combat en PHP (... désolé.) Voici ce qui existe jusqu'à présent:
- Il existe (jusqu'à présent) deux types d'entités qui peuvent participer au combat. Appelons-les simplement joueurs et PNJ. Leurs données sont déjà assez bien écrites.
- Lorsqu'elles sont impliquées dans un combat, ces entités sont enveloppées d'un autre objet dans la base de données appelé a
Combatant
, qui leur donne des informations sur le combat en question. Ils peuvent être impliqués dans plusieurs combats à la fois. - J'essaie d'écrire le moteur logique du combat en y injectant des combattants.
- Je veux pouvoir tout simuler pour les tests.
Afin de séparer la logique et les données, je veux avoir deux interfaces / classes de base, l'une étant ICombatantData
et l'autre ICombatantLogic
. Les deux implémenteurs de données seront l'un pour les objets réels stockés dans la base de données et l'autre pour mes objets fictifs.
Je suis maintenant confronté à des incertitudes quant à la conception du côté logique des choses. Je peux avoir un implémenteur pour chacun des joueurs et des PNJ, mais j'ai un problème. Un combattant doit pouvoir retourner l'entité qu'il enveloppe. Cette méthode getter doit-elle faire partie de la logique ou des données? Je suis convaincu que cela devrait être dans les données, car la partie logique est utilisée pour exécuter le combat, et ne sera pas disponible si quelqu'un cherche simplement des informations sur un combat à venir. Mais les classes de données ne séparent que la maquette de la base de données, pas le joueur du PNJ. Si j'essaie d'avoir deux classes enfants de l'implémentateur de données DB, une pour chaque type d'entité, comment puis-je l'architecturer tout en gardant mes maquettes dans la boucle? Ai-je besoin d'une troisième interface comme IEntityProvider
celle que j'injecte dans les classes de données?
De plus, avec certaines des idées que j'ai envisagées, je pense que je vais devoir mettre en place des contrôles pour vous assurer que vous ne faites pas de différence, comme faire en sorte que la logique d'un PNJ enveloppe accidentellement les données d'un joueur. Cela a-t-il un sens? Est-ce une situation qui serait même possible si l'architecture est correcte, ou la bonne conception l'interdirait-elle complètement, donc je n'ai pas besoin de la vérifier?
Si quelqu'un pouvait m'aider à simplement mettre en page un diagramme de classe ou quelque chose pour cela, cela m'aiderait beaucoup. Merci.
Éditer
Il est également utile de noter que la classe de données fictives n'a pas vraiment besoin de la Entity
, car je vais simplement spécifier directement tous les paramètres comme les statistiques de combat. Alors peut-être que cela affectera la conception correcte.
Combatant.entity
pas utilisée pendant le combat et ne devrait donc pas exister. Peut-être avez-vous besoin d'une autre classe comme celleEntityVsEntityCombat
qui encapsule la logique de combat, contient lesEntity <--> Combatant
mappages et met à jour lesEntity
états une fois le combat terminé? Peut-être que quelques informations supplémentaires sur votre architecture actuelle pourraient vous aider.