Actualiser MiniJeux/ReadMe.md
This commit is contained in:
@@ -1,5 +1,12 @@
|
||||
# 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:
|
||||
|
||||
* 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 !)
|
||||
* 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