Refonte Zelda Like
Refactorisation d'un jeu Java avec implémentation de Design Patterns.
01 — Le contexte de la refonte
Souvent, dans un cursus d’apprentissage, les premiers projets fonctionnels cachent un code source chaotique (“Spaghetti code”). Ce projet consistait précisément à reprendre un ancien Zelda Like développé précédemment (en Java) et à le restructurer de A à Z.
L’objectif n’était pas d’ajouter des fonctionnalités, mais de prouver notre capacité à améliorer la maintenabilité du code source, optimiser les performances du jeu, et surtout y introduire des normes professionnelles.
02 — Séparation des préoccupations (MVC)
Le problème initial : Les anciennes classes mélangeaient l’affichage graphique (JavaFX), la logique métier (points de vie, dégâts) et les contrôles clavier. Ce fort couplage rendait toute évolution dangereuse.
La solution : Nous avons implémenté l’architecture Modèle-Vue-Contrôleur (MVC). Les données du jeu (le Modèle) ont été totalement séparées de la boucle de rendu visuel (la Vue). Les entrées clavier ont été déportées dans un Contrôleur dédié, rendant le code testable et compréhensible.
03 — Flexibilité des comportements (Design Patterns)
Dans l’ancienne version, chaque type d’ennemi redéfinissait manuellement sa propre logique de déplacement via d’immenses blocs conditionnels (if/else ou switch).
En utilisant le Design Pattern Strategy, nous avons encapsulé les algorithmes de déplacement dans des classes d’objets distinctes et interchangeables. De même, le Pattern Decorator a été utilisé pour gérer les statistiques des personnages (application d’armures ou d’armes) de manière empilable, sans modifier la classe de base du joueur. Enfin, le Singleton garantit l’unicité du Game Manager.
04 — Résultat sur la clarté du code
Ce travail en équipe de 4 personnes a mis en évidence l’importance vitale du Refactoring continu. En appliquant les principes SOLID, le code est devenu non seulement plus court, mais il “raconte” ce qu’il fait. L’ajout futur d’un nouvel ennemi ou d’une nouvelle arme nécessitera la création d’une seule petite classe, sans aucun risque de casser le moteur du jeu.
