Dans son état actuel, le programme est difficile à valider en raison de multiples points :
- Les méthodes sont longues et impliquent de nombreux niveaux d'indentation, augmentant la complexité du code.
- Certaines méthodes enchaînent plusieurs conditions différentes, le tout au sein de 2 boucles while imbriqués.
- À un endroit du code, on retrouve l'utilisation d'un
goto
qui agis comme une boucle pour pour lire les entrées de l'utilisateur. - la vérification de victoire est codé en dur à travers une énorme condition de AND et OR enchaînés à la suite.
- dans
tourJoueur
, le code contiens des condition imbriqués dans un switch, lui même dans une boucle while. - Dans le puissance 4, il reste du code mort commenté dans le fichier.
Tous ces points rendent le code difficile à lire, à comprendre et à valider, de part la longueur du code ou la complexité des conditions. (imbrication de boucles, de conditions, de switch, de goto, etc.
Pour résoudre ces problèmes, il sera envisageable de mettre en place certaines choses :
- Diviser les méthodes en plusieurs méthodes plus petites, pour réduire la complexité du code
- Utiliser des structures de données pour simplifier la vérification de victoire
- Réduire l'imbrication des boucles et des conditions
- Remplacer
goto
par des boucles - Supprimer le code mort
- Utiliser des tests unitaires pour valider le code et s'assurer de son bon fonctionnement
- Ajouter des conditions de contrôle pour s'assurer des paramètres d'entré des méthodes
Pour le développement des fonctionnalités manquantes, il sera nécessaire :
-
d'extraire la logique du joueur dans une classe dédié (
AbstractPlayer
), pour permettre l'ajout d'unComputerPlayer
en plus duHumanPlayer
. Chacun auront une logique dédié pour jouer un coup. Par exemple, leHumanPlayer
se servira le l'implémentation deIGui
pour demander à l'utilisateur de jouer un coup, tandis que leComputerPlayer
utilisera une logique "calculée" pour jouer un coup. -
pour la persistance des données, il faudra créer une classe
GameSerializer
qui permettra de sauvegarder et charger les données. Sur ce point, j'ai beaucoup de difficulté à imaginer une solution. En effet, pour respecter les principes de conceptions, l'idée aurait été de garder le plus d'attributs de classe privée. Hors, pour sauvegarder les données, nous aurions besoin de les rendre accessible, brisant ainsi l'idée que nos attributs de classe doivent être privé.