Notre application s'articule autour d'une classe principale, la classe Game. Celle-ci est entourée par la quasi-totalité des autres classes.
Elle utilise donc la classe Player, laquelle est utilisée dans deux lieux très importants. Les methodes étant lié a la gestion des joueurs sont majoritairement lié a une interface nommé "IPLAYER", nous permettant d'imaginer, au besoin, d'autre règles pour ces methodes la. Le premier est notre ScoreBoard, un dictionnaire liant un player et un score. La classe Player est aussi utilisée par une liste qui nous permet de faire fonctionner correctement la partie. Le choix a été fait de ne pas se servir du ScoreBoard pour cela, afin d'éviter tout problème.
Elle utilise donc la classe Player, laquelle est utilisée dans deux lieux très importants. Les méthodes liées à la gestion des joueurs sont majoritairement basées sur une interface nommée "IPLAYER", nous permettant d'imaginer, au besoin, d'autres règles pour ces méthodes-là. Le premier lieu d'utilisation est notre ScoreBoard, un dictionnaire liant un player et un score. La classe Player est aussi utilisée par une liste qui nous permet de faire fonctionner correctement la partie. Le choix a été fait de ne pas se servir du ScoreBoard pour cela, afin d'éviter tout problème.
Évidemment, une game ne serait rien sans un "board" ! C'est donc une classe, composée d'une liste encapsulée de cells. Cette classe nous permet de stocker et d'exécuter certaines méthodes, comme l'ajout des tuiles.
@ -18,11 +18,11 @@ Le QWIRKLE est composé de tuiles. Chez nous, les tuiles représentent deux clas
La seconde classe des tuiles est très importante, c'est celle des "TilesBag". Elle est utilisée à deux endroits. Cette classe, qui nous permet de créer des listes de tuiles, est donc appelée à deux reprises : dans Game, où elle sert de pioche pour les joueurs, et dans Player, pour stocker les tuiles de chaque joueur.
Pour compléter sur la gestion des tuiles, dans Game, plusieurs méthodes s'occupent de cela. Tout d'abord, une fonction "swap" et une autre de distribution des tuiles, essentielles pour le bon fonctionnement du jeu.
Pour compléter sur la gestion des tuiles, dans Game, plusieurs méthodes s'en occupent. Tout d'abord, une fonction "swap" et une autre de distribution des tuiles, essentielles pour le bon fonctionnement du jeu.
Plusieurs autres fonctions implémentent les tuiles et globalement les règles de jeu. Elles sont liées à l'interface "IRULES" et sont écrites dans la classe Game. On y retrouve, par exemple, trois algorithmes : un qui permet de vérifier si une tuile peut être placée là où l'utilisateur le souhaite, un autre concernant l'attribution des points, et un dernier qui gère la fin de partie.
Pour terminer le tour de l'architecture, il faut aussi parler de l'application console, celle-ci est abonné a 4 évenement de game, permettant une optmisation et une clarté du code. Les evenements sont trés utilisé pour indiquer ce qu'il se passe a l'utilisateur, celle-la lui permettre de savoir pourquoi une tuile n'est pas placé, pourquoi un nom de joueur n'est pas accepté, qui est le prochain joueur et qui est le dernier joueur de la partie.
Pour terminer le tour de l'architecture, il faut aussi parler de l'application console, celle-ci est abonnée à quatre événements de Game, permettant une optimisation et une clarté du code. Les événements sont très utilisés pour indiquer ce qu'il se passe à l'utilisateur ; ils lui permettent de savoir pourquoi une tuile n'est pas placée, pourquoi un nom de joueur n'est pas accepté, qui est le prochain joueur et qui est le dernier joueur de la partie.
