Dépendance circulaire pour un système de gestion d'événements

Bonjour,

Je crée actuellement un jeu et j'ai une question concernant un problème d'inclusion circulaire. J'ai actuellement 3 classes :

Game : qui dessine le monde et fait appel à une instance d'EventHandler afin d'obtenir une liste d'Event. La méthode membre "process" est ensuite appelée sur chaque événement de cette liste (event->process(...)).

EventHandler : qui fait appel à du code dépendant d'une API donnée afin de récupérer une liste d'événements pour cette API, et qui les traduit en Event (pour minimiser la dépendance à une API donnée au sein de mon programme).

Event : qui représente un événement pour le jeu (notamment des entrées utilisateur), et qui possède une méthode "process" ayant en paramètre un pointeur vers un objet Game sur lequel il pourra appeler certaines fonctions (par exemple demander au jeu de mettre fin à la boucle principale dans le cas d'un événement "quitter", déclencher sur pression de la touche "esc" par l'utilisateur par exemple). Event est en fait une classe abstraite spécialisée dans différentes classes filles (Event_Quit, Event_MouseMove, etc.).

On le voit donc, j'ai une dépendance circulaire du type :

... -> Event -> Game -> EventHandler -> Event -> ...

(où "-> ..." signifie "déclare une donnée membre de type pointeur sur un ..., ou a une fonction membre qui retourne un pointeur vers un/des ..., dans son header").

Ca fonctionne (avec la forward declaration de Game dans le header d'Event), mais ça n'est pas forcément très beau (les inclusions circulaires c'est mal il parait).

Certes il y aurait des moyens de casser la chaîne, en délégant l'exécution des événements à Game par exemple (un gros switch sur le type d'Event, avec un cast eventuel, et c'est lui qui exécute les Event qui deviendraient alors purement descriptifs, sans actions). Mais bien sûr c'est encore plus laid.

Du coup je me demandais qu'elle est la façon propre de gérer ce problème classique ?

Merci d'avance :D

Bonjour,

Une solution est d'utiliser des "déclarations anticipées" :

Code:

---

1 2 3 4 5 6

class Foo;   class A { Foo & m_foo; }

---

Ainsi, tu n'as pas besoin d'include foo.h tant que tu ne met que des pointeurs/références de Foo.

Ensuite, tu mets toutes les implémentations des méthodes dans a.cpp et tu inclus foo.h dans a.cpp.

Citation:

---

Envoyé par syntaxerror

Ca fonctionne (avec la forward declaration de Game dans le header d'Event), mais ça n'est pas forcément très beau (les inclusions circulaires c'est mal il parait).

---

Citation:

---

Envoyé par syntaxerror

Certes il y aurait des moyens de casser la chaîne, en délégant l'exécution des événements à Game par exemple (un gros switch sur le type d'Event, avec un cast eventuel, et c'est lui qui exécute les Event qui deviendraient alors purement descriptifs, sans actions). Mais bien sûr c'est encore plus laid.

---

Je pense que c'est la solution si tu veux éviter les déclarations anticipées. Pas besoin d'un gros switch. Un Event correspond à un et un seul type. Dans la classe Game, tu écris une fonction par type (par Event) qui traite l'évent (qui est le mieux placé pour modifier le Game ?).

Salut,

ce que tu racontes, si je l'ai bien compris, n'a rien de choquant, surtout dans le jeu-vidéo où bon nombre d'éléments peuvent agir sur "le" jeu.

bonjour,
je ne vois pas ce que tu trouves choquant dans l'histoire. Je pense même que c'est une meilleure répartition de responsabilités que de confier à Game l'exécution des events.
Si tu imaginais qu'un Event puisse être couplé à autre chose qu'un Game, tu pourrais abstraire la notion de cible d'évènement (dont Game deviendrait malgré tout une implémentation), mais jusqu'à preuve du contraire (c'est à dire réutilisation concrète du même système d'évènements dans un autre jeu) c'est de l'overengeneering AMHA.