From 6e2c554af9f618047745243460d8a93c27400fb1 Mon Sep 17 00:00:00 2001 From: Grizouille Date: Tue, 9 Dec 2025 16:01:02 +0000 Subject: [PATCH] Actualiser MiniJeux/ReadMe.md --- MiniJeux/ReadMe.md | 43 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 42 insertions(+), 1 deletion(-) diff --git a/MiniJeux/ReadMe.md b/MiniJeux/ReadMe.md index d6f2745..49bd8f7 100644 --- a/MiniJeux/ReadMe.md +++ b/MiniJeux/ReadMe.md @@ -1,5 +1,12 @@ # But du jeu +Après avoir découvert le fonctionnement de `MiniJeuBourin`, nous allons progressivement améliorer notre code.
+Nous commencerons par un refactoring, puis nous apprendrons à écrire des tests en utilisant la méthode TDD (Test Driven Development).
+Au fil de cette évolution, nous ajouterons de nouvelles interfaces, des classes, ainsi qu’une factory pour mieux organiser la création d’objets.
+Nous utiliserons également des mocks pour isoler certaines parties du code lors des tests.
+L’objectif final est de comprendre et pratiquer en profondeur le principe de polymorphisme. + + ## 1. Utiliser le projet MiniJeuBourin pour: * Créer une interface (IActionPpc) commune pour les `actions` (pierre, papier, ciseaux) (Name, bool ToWin(other)) @@ -18,4 +25,38 @@ * Ajouter une interface commune pour tous les jeux (IGame (Name, Start, Stop)) * Ajouter une classe `PierrePapierCiseaux` à la solution en TDD en implémentant `IGame`. * Ajouter le jeu *LePendu* à la solution en TDD en implémentant `IGame`. -* Création d'un menu pour séléctionner le jeu (doit etre auto !) \ No newline at end of file +* Création d'un menu pour séléctionner le jeu (doit etre auto !) + +Bien sûr ! Voici une **annexe pédagogique** contenant la définition de tous les mots-clés mentionnés. + +--- + +# **Annexe — Définitions des mots-clés** + +* **Refactoring** + * Le refactoring consiste à **améliorer la structure interne du code** sans changer son comportement. +Objectif : rendre le code plus clair, plus simple à maintenir et plus évolutif. +* **TDD (Test Driven Development)** + * Méthode de développement où l’on écrit **d’abord les tests**, puis le code qui permet de les faire passer. + * Cycle classique : + 1. **Red** – écrire un test qui échoue + 2. **Green** – écrire le code minimum pour le faire réussir + 3. **Refactor** – améliorer le code tout en gardant les tests au vert +* **Interface** + * Une interface définit **un contrat**, c’est-à-dire une liste de méthodes que les classes doivent implémenter. +Objectif : garantir qu’un groupe de classes offre les mêmes fonctionnalités, tout en pouvant avoir des comportements différents. +* **Classe** + * Une classe est un **plan de construction** pour créer des objets. +Elle regroupe des données (attributs) et des comportements (méthodes). +* **Factory** + * Une *factory* (ou *factory pattern*) est un modèle de conception permettant de **centraliser la création d’objets**. +Objectif : éviter que le reste du code sache *comment* les objets sont construits, ce qui facilite leur remplacement ou leur évolution. +* **Mock** + * Un mock est un **faux objet** utilisé dans les tests pour simuler le comportement d’un objet réel. + * Objectif : + 1. isoler une partie du code + 2. éviter les dépendances lourdes (base de données, API, fichiers…) + 3. tester uniquement ce qui doit l’être +* **Polymorphisme** + * Principe fondamental de la programmation orientée objet qui permet à **différentes classes** d’être utilisées **comme si elles étaient du même type**, grâce à une interface ou une classe mère commune. + * Objectif : écrire du code flexible capable de fonctionner avec plusieurs implémentations différentes.