63 lines
3.6 KiB
Markdown
63 lines
3.6 KiB
Markdown
# 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))
|
||
* Implémenter les classes `actions` en utilisant TDD.
|
||
* Créer une factory pour le choix auto de l'ordinateur
|
||
* Créer une autre factory pour faciliter le choix de l'utilisateur grace à des nombres (1:pierre,2:papier...)
|
||
* Implémenter le Program pour mettre en place le jeu.
|
||
|
||
## 2. Les Mocks dans les tests
|
||
|
||
* Utiliser FakeItEasy pour simuler l'entrée/sortie dans la console
|
||
* Modifier les tests existant
|
||
|
||
## 3. Ajouter un 2eme jeu *Le Pendu*
|
||
|
||
* 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 !)
|
||
|
||
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.
|