Bonjour,
je voulais savoir si le module gui.cc pouvait inclure player.h , map.h , ball.h . en effet celui-ci inclut simulation.h qui va obligatoirement appeler les 3 modules en question pour pouvoir faire les dessins .... Mais ceci serait plus rapide si ça se faisait directement ...
Merci
Bonjour,
Comme vous dites correctement, la donnée du projet dit explicitement que l'appel de player, map et ball de la part de gui doit forcément se faire par l'intermédiaire du module simulation (voir par exemple da Figure 9a).
Cette choix de design, bien que un peu plus laborieuse, a comme avantage de pouvoir plus facilement généraliser l'architecture à un programme générique, en limitant les dependences des modules de haut niveau (comme par exemple gui) sur les modules spécifiques à notre projet (player, ball et map).
Bonne journée,
Andrea Oliveri
je confirme qu'il faut passer par simulation pour obtenir les informations des player, ball, obstacle
Mon message restrictif concernant l'interdiction d'inclure include Player.h, Ball.h, Map.h dans simulation.h concerne les projets qui ont un module simulation SANS classe Simulation. Un tel module n'a besoin d'exporter que des fonctions à l'extérieur du module, ce qui justifie cette interdiction.
Si vous avez développé une classe Simulation, il est normal que l'interface du module contienne l'interface de la classe Simulation qui elle-même a le droit d'avoir des attributs liés aux types Player, Ball, Map... DONC dans ce contexte c'est normal et autorisé d'aussi inclure les interface Player.h, Ball.h map.h si on ne peut pas faire autrement (sinon ça ne compile pas).
Cela dit, pour revenir à la donnée:
-> seules des méthodes de la classe simulation peuvent être utilisées dans projet et dans gui.
-> on ne peut pas créer des variables ou avoir des paramètres de type Player, Ball, Map ( ou Obstacle) dans projet et gui.
----------- Le message précédent concerne ceux qui ont écrit un module simulation SANS classe Simulation --------
----------- dans ce cas le module simulation est un module "à-la-C" qui exporte seulement des fonctions ------------
ce message donnait déjà la réponse:
https://moodlearchive.epfl.ch/2018-2019/mod/forum/discuss.php?d=16463&parent=32568
votre fichier simulation.h ne doit pas contenir player.h, ball.h ni map.h (ou obstacle.h si vous avez choisi ce nom) car cela introduit une dépendance vis à vis de ces modules player, ball, et map partout où vous faites l'include de simulation.h. Normalement ni projet.cc ni gui.cc ne doivent connaiître ni utiliser les types Player, Ball, Map (ou Obstacle).
je cite la donnée:
le module simulation est le seul module dont on peut appeler des fonctions en dehors du Modèle (Fig 9).
Seule votre implémentation simulation.cc peut faire l'include de player.h, ball.h ni map.h
Selon l'architecture indiquée par la donnée, le module gui peut aussi travailler avec des entités génériques de plus bas niveau tels que POINT, CERCLE ou CARRE qui peuvent être définis dans le module utilitaire tools. L'interface de tools.h peut être utilisée par gui.cc
https://moodlearchive.epfl.ch/2018-2019/mod/resource/view.php?id=1013833
Par ailleurs, votre morceau de code viole l'encapsulation du module simulation en montrant l'attribut players à l'extérieur du module simulation. Il est formellement interdit de rendre des attributs publics, même s'il s'agit d'attribut de classe (static).
Que peut-on faire dans le cadre de l'architecture indiquée par la donnée: le module simulation a le droit de fournir des getters pour les nombres de cellules, de Player, Ball, Obstacles. De même il peut fournir des données des types de bas-niveau tel que le CERCLE correspondant à un Player d'indice i. De même qu'il peut founir les indices ligne/colonne d'un obstacle, ou un CARRE. le module gui est responsable de son coté de convertir les coordonées du jeu en coordonnées GTK pour l'affichage.
Bonjour,
Vous nous dites que le module gui peut uniquement recevoir des informations du style "créer un cercle".
Mais il faudrait aussi fournir, pour dessiner les joueurs, en plus d'une liste de cercle, une liste de barre de chargement, afin de les afficher avec une fonction du type draw_barre_chargement(double angle, Point centre, double rayon ?).
Cette approche nécessite de créer justement plusieurs liste avec leurs données qui sont liées entre elles, dans notre cas, une liste de cercle, et une d'arc de cercle, pour se soumettre à la contrainte de demander à gui d'afficher uniquement des formes géométriques.
Je croyais que l'on créait des classes justement pour ne pas avoir besoin de transmettre individuellement des informations de plusieurs type liées entre elles.
Je vous ai joins à ce message un shéma avec les différents transmissions d'information selon les deux méthodes.
Si on suit votre idée on se retrouve avec des méthode dessin() dans les
classes Player, Ball et Map. Or dans l'architecture MVC adoptée cette
année c'est le module gui qui a la responsabilité de dessiner, pas les modules du Modèle.
De plus il n'y a pas besoin de dupliquer l'information:
Le CERCLE utilisé pour le dessin par gui devrait être le même CERCLE qu'un Player (ou que simulation) exploite déjà pour les détections de collision.
Lorsque cette information est récupérée pour le dessin, l'ajout du paramètre du compteur (barre de chargement) suffit pour que gui sache le traduire en arc de cercle pour le CERCLE associé à un Player.
Bonjour,
Pour déplacer les joueurs je veux créer une fonction dans le module player. Ai-je le droit d'inclure map.h dans player afin de donner des informations aux joueurs sur la carte? Si nous sommes obligé de régler ce problème dans simulation, cela ne poserait-il pas de problème d'encapsulation (simulation doit accéder à la postion des joueurs)?
les 2 approches proposées sont possibles puisque tous ces modules font partie du sous-système "Modèle".
Il est seulement demandé de documenter dans le rapport votre motivation pour ajouter une dépendance supplémentaire directe entre map et player . Sans une telle dépendance supplémentaire, c'est le module "simulation" qui doit jouer le role de relais soit pour transmettre l'information entre les modules player et map, soit pour résoudre le problème en partie au niveau simulation (niveau d'abstraction supérieur) tout en délégant ce qui peut l'être aux modules map et player.