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.
É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.
Le QWIRKLE est composé de tuiles. Chez nous, les tuiles représentent deux classes, deux enums. La première est une classe simple contenant une couleur et une forme, piochées dans les deux enums, une de couleur, l'autre de forme. Cette classe est correctement sécurisée aussi, en possédant des getters.
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.
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.
