comment représenter les données événementielles dans la communication événementielle ?

Question

J'essaie de créer un système central de répartition des événements en utilisant une sorte de modèle Observer pour mon petit projet RPG, et j'ai besoin de conseils sur la meilleure façon de représenter les données d'événement.

J'aurai un EventManager qui enregistre les classes d'écoute pour différents types d'événements définis dans une énumération statique telle que Event_Input_KeyPressed ou Event_Game_ActorMoved.Il stockera les événements dans une file d'attente et les distribuera aux écouteurs correspondants, qui auront chacun une méthode handleEvent(Event e) ou quelque chose du genre.

Chaque événement sera un objet de type Event, qui contient des données telles que son type d'événement.

Ma question est la suivante : étant donné que la nature des données d'événement diffère considérablement selon les types d'événements, comment ces données doivent-elles être représentées ?Je ne sais pas encore exactement quels types d'événements je souhaiterai créer à l'avenir, je souhaite donc que cela soit aussi flexible que possible.Par exemple, un événement pourrait déclencher d'autres événements si certaines conditions sont vraies (c.-à-d.lorsque le joueur appuie sur la touche d'action, une porte s'ouvre si le joueur se trouve à un certain endroit et possède une clé).XML ou les scripts sont-ils un bon choix ?Une autre façon à laquelle je peux penser est de créer une classe personnalisée pour chaque événement général, comme ActorEvent ou MenuEvent, mais cela semble vraiment inefficace et rigide.De plus, comme certains objets tels que Character n'ont besoin de connaître que des événements très spécifiques, comme lorsque la touche "w" est enfoncée, je suppose qu'ils n'ont pas besoin d'être avertis lorsque d'autres touches comme "h" sont enfoncées.Est-il viable de créer des types d’événements aussi spécifiques ou existe-t-il un meilleur moyen ?c'est à dire.Event_Input_KeyPressed_W

Merci

Answer 1

1. Créez des mises en œuvre concrètes de vos événements, allant du Event objet de base.Premièrement, il sera plus facile de distribuer les objets - c'est-à-dire dans votre file d'attente, il vous suffira de faire un instanceof pour déterminer comment manipuler l’objet.
2. Votre code d'écouteur d'événements devient BEAUCOUP plus simple et plus étroitement contrôlé.Il n'y a aucune chance qu'un événement de souris soit transmis à un événement clé.De plus, vous n'aurez pas besoin de tester et de diffuser l'objet événement au niveau de l'écouteur.
3. Je ne vois pas pourquoi vous ne pourriez pas créer un écouteur d'événement "filtré" qui voudra uniquement être informé d'une condition particulière d'un événement particulier. En fait, je pense que c'est une bonne idée.
4. Je concevoirais probablement une sorte de mécanisme de répartition enfichable.Cela signifie que lorsque vous ajoutez un nouveau type d'événement, vous n'aurez pas besoin de mettre à jour la file d'attente, vous pouvez simplement enregistrer un nouveau répartiteur.En fonction de ce que vous souhaitez réaliser, votre file d'attente transmettra l'événement au répartiteur (ce qui permettra au répartiteur d'obtenir la liste des auditeurs).Le répartiteur déterminerait s'il sait comment gérer l'événement ou non.Le répartiteur enverrait alors l'événement aux écouteurs requis (et en fonction de ce que vous souhaitez réaliser), renverrait un résultat indiquant si l'événement a été distribué ou non.

C'est MHO

Answer 2

• Comme vous dites que la structure de différents types d'événements est différente, il est préférable de créer des classes concrètes pour chaque événement.Vous n'avez pas besoin de créer une classe pour chaque clé!Mais généralement des événements de clavier
• Vous dites que des caractères ne doivent être informés que d'une clé spécifique.Je ne sais pas quelle est la surcharge de notification du personnage et que cet objet ignorer les clés non liées, mais s'il s'agit d'un modèle commun entre les classes, vous disposez de 10 classes différentes pouvant réagir à un ensemble spécial de clés, ce serait bienPour ne pas répéter des codes et implémenter une couche de répartiteur entre événements et auditeurs.Un type de distinct peut être KeyFilterDisPatcher qui reçoit une liste des clés et des filtres basé sur cela.Un autre type de répartiteurs peut être SEQDispatcher qui ne perturbe que les auditeurs si plusieurs événements sont pris en compte dans un ordre spécifique! J'aime l'idée de Disthaber Pluggable MADPRRARAMMER.Aussi, vous voudrez peut-être créer des tuyaux de répartiteurs!