Actualiser MiniJeux/ReadMe.md
This commit is contained in:
@@ -1,5 +1,12 @@
|
|||||||
# But du jeu
|
# But du jeu
|
||||||
|
|
||||||
|
Après avoir découvert le fonctionnement de `MiniJeuBourin`, nous allons progressivement améliorer notre code. <br/>
|
||||||
|
Nous commencerons par un refactoring, puis nous apprendrons à écrire des tests en utilisant la méthode TDD (Test Driven Development).<br/>
|
||||||
|
Au fil de cette évolution, nous ajouterons de nouvelles interfaces, des classes, ainsi qu’une factory pour mieux organiser la création d’objets.<br/>
|
||||||
|
Nous utiliserons également des mocks pour isoler certaines parties du code lors des tests.<br/>
|
||||||
|
L’objectif final est de comprendre et pratiquer en profondeur le principe de polymorphisme.
|
||||||
|
|
||||||
|
|
||||||
## 1. Utiliser le projet MiniJeuBourin pour:
|
## 1. Utiliser le projet MiniJeuBourin pour:
|
||||||
|
|
||||||
* Créer une interface (IActionPpc) commune pour les `actions` (pierre, papier, ciseaux) (Name, bool ToWin(other))
|
* Créer une interface (IActionPpc) commune pour les `actions` (pierre, papier, ciseaux) (Name, bool ToWin(other))
|
||||||
@@ -19,3 +26,37 @@
|
|||||||
* Ajouter une classe `PierrePapierCiseaux` à la solution en TDD en implémentant `IGame`.
|
* Ajouter une classe `PierrePapierCiseaux` à la solution en TDD en implémentant `IGame`.
|
||||||
* Ajouter le jeu *LePendu* à 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 !)
|
* 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.
|
||||||
|
|||||||
Reference in New Issue
Block a user