296 lines
7.6 KiB
Markdown
296 lines
7.6 KiB
Markdown
# 🧠 Architecture & Bonnes Pratiques – MiniJeuxFinal
|
||
|
||
Le projet **MiniJeuxFinal** a été conçu comme un support pédagogique et technique visant à appliquer des **bonnes pratiques de conception logicielle** en C#.<br/>
|
||
L’objectif principal est d’obtenir un code **maintenable**, **testable** et **facilement extensible**, même pour un projet de petite taille.
|
||
|
||
|
||
## 🎯 Objectifs de conception
|
||
|
||
* Ajouter de **nouveaux jeux** sans modifier l’existant
|
||
* Séparer clairement :
|
||
* le **cœur métier**
|
||
* l’**interface utilisateur**
|
||
* les **dépendances techniques**
|
||
* Favoriser la **testabilité**
|
||
* Éviter le couplage fort et le code rigide
|
||
|
||
```
|
||
MiniJeuxFinal/
|
||
│
|
||
├── MiniJeuxFinal.csproj # Fichier projet C# .NET 9
|
||
│
|
||
├── Program.cs # Point d'entrée de l'application
|
||
│
|
||
├── GameFactory/
|
||
│ └── PierrePapierCiseauxGameFactory.cs # Création du jeu
|
||
│
|
||
├── Games/
|
||
│ ├── IGame.cs # Interface générale d'un jeu
|
||
│ ├── IAction.cs # Interface générale d'une action
|
||
│ ├── IPlayer.cs # Interface générale d'un joueur
|
||
│ │
|
||
│ ├── PierrePapierCiseaux/ # Implémentation spécifique du jeu PPC
|
||
│ │ ├── PierrePapierCiseauxGame.cs # Classe principale du jeu PPC
|
||
│ │ │
|
||
│ │ ├── Actions/ # Actions spécifiques au PPC
|
||
│ │ │ ├── IActionPpc.cs # Interface spécialisée (hérite de IAction)
|
||
│ │ │ ├── StoneAction.cs # Pierre
|
||
│ │ │ ├── PaperAction.cs # Papier
|
||
│ │ │ └── ScissorsAction.cs # Ciseaux
|
||
│ │ │
|
||
│ │ ├── Factories/ # Factories pour créer les actions PPC
|
||
│ │ │ ├── IActionPpcFactory.cs # Interface des factories PPC
|
||
│ │ │ ├── InputActionFactory.cs # Factory pour l'entrée utilisateur
|
||
│ │ │ └── RandomActionFactory.cs# Factory aléatoire (IA)
|
||
│ │ │
|
||
│ │ └── Players/
|
||
│ │ └── PlayerPpc.cs # Joueur spécialisé pour le PPC
|
||
│ │
|
||
│ └── Trash/ # Anciennes versions ou brouillons
|
||
│ ├── Pendu.cs
|
||
│ └── Ppc.cs
|
||
│
|
||
├── Ui/
|
||
│ └── GameRunnerConsole.cs # Orchestrateur UI Console (affichage)
|
||
│
|
||
├── Wrappers/ # Abstractions des dépendances externes
|
||
│ ├── IConsole.cs # Interface pour la console
|
||
│ └── ConsoleService.cs # Implémentation réelle de IConsole
|
||
```
|
||
|
||
## 🧩 Architecture Hexagonale (Ports & Adapters)
|
||
|
||
Le projet applique une **architecture hexagonale** (aussi appelée *Ports & Adapters*).
|
||
|
||
Cette architecture vise à **isoler le cœur métier** de toute dépendance externe (UI, console, hasard, etc.).
|
||
|
||
|
||
### 🧠 Cœur métier (Domaine)
|
||
|
||
Le domaine est situé dans le dossier :
|
||
|
||
```
|
||
Games/
|
||
```
|
||
|
||
Il contient :
|
||
|
||
* les règles du jeu
|
||
* les interactions entre joueurs
|
||
* les actions possibles
|
||
|
||
👉 Le domaine **ne dépend d’aucune implémentation technique**.
|
||
|
||
|
||
### 🔌 Ports (Interfaces)
|
||
|
||
Les **ports** sont définis sous forme d’interfaces et représentent les contrats du domaine.
|
||
|
||
**Ports métier :**
|
||
* `IGame`
|
||
* `IPlayer`
|
||
* `IAction`
|
||
* `IActionPpc`
|
||
|
||
**Ports techniques :**
|
||
|
||
* `IConsole`
|
||
|
||
👉 Le domaine exprime **ce dont il a besoin**, sans connaître comment c’est fait.
|
||
|
||
|
||
### 🔧 Adapters (Implémentations)
|
||
|
||
Les **adapters** sont les implémentations concrètes des ports.
|
||
|
||
**Adapters entrants (Driving Adapters) :**
|
||
|
||
* `GameRunnerConsole`
|
||
|
||
* Pilote le jeu depuis l’UI console
|
||
* Traduit les actions utilisateur vers le domaine
|
||
|
||
**Adapters sortants (Driven Adapters) :**
|
||
|
||
* `ConsoleService`
|
||
* `InputActionFactory`
|
||
* `RandomActionFactory`
|
||
|
||
|
||
### 🧭 Flux des dépendances
|
||
|
||
✔ Les dépendances vont toujours **vers le domaine**<br/>
|
||
❌ Le domaine ne dépend jamais des adapters
|
||
|
||
```
|
||
UI / Infrastructure → Interfaces → Domaine
|
||
```
|
||
|
||
|
||
## 🧩 Bonnes pratiques et patterns appliqués
|
||
|
||
|
||
### 1. Single Responsibility Principle (SRP)
|
||
|
||
**Application :**
|
||
|
||
* Chaque classe a une responsabilité unique :
|
||
* logique métier
|
||
* affichage
|
||
* création d’objets
|
||
* accès à la console
|
||
|
||
**Pourquoi :**
|
||
|
||
* Code plus lisible
|
||
* Maintenance facilitée
|
||
* Changements localisés
|
||
|
||
|
||
### 2. Programmation orientée interfaces
|
||
|
||
**Application :**
|
||
|
||
* Interfaces génériques (`IGame`, `IPlayer`, `IAction`)
|
||
* Interfaces spécialisées par jeu (`IActionPpc`)
|
||
* Abstractions techniques (`IConsole`)
|
||
|
||
**Pourquoi :**
|
||
|
||
* Faible couplage
|
||
* Remplacement facile des implémentations
|
||
* Meilleure extensibilité
|
||
|
||
|
||
### 3. Dependency Inversion Principle (DIP)
|
||
|
||
**Application :**
|
||
|
||
* Le domaine dépend uniquement d’abstractions
|
||
* Les implémentations concrètes sont injectées via des factories
|
||
|
||
**Pourquoi :**
|
||
|
||
* Indépendance technologique
|
||
* Testabilité accrue
|
||
* Code plus robuste
|
||
|
||
|
||
### 4. Factory Pattern
|
||
|
||
**Application :**
|
||
|
||
* `PierrePapierCiseauxGameFactory` pour créer un jeu complet
|
||
* Factories d’actions (`InputActionFactory`, `RandomActionFactory`)
|
||
|
||
**Pourquoi :**
|
||
|
||
* Centralisation de la création d’objets
|
||
* Suppression de la logique d’instanciation du métier
|
||
* Facilite l’évolution
|
||
|
||
|
||
### 5. Strategy Pattern
|
||
|
||
**Application :**
|
||
|
||
* Chaque action (Pierre, Papier, Ciseaux) est une stratégie distincte
|
||
* Les joueurs utilisent des comportements interchangeables
|
||
|
||
**Pourquoi :**
|
||
|
||
* Suppression des `switch` complexes
|
||
* Ajout de nouvelles actions sans modification du code existant
|
||
* Code plus propre et extensible
|
||
|
||
|
||
### 6. Open / Closed Principle (OCP)
|
||
|
||
**Application :**
|
||
|
||
* Extension par ajout de classes
|
||
* Aucun code existant modifié pour ajouter :
|
||
|
||
* un nouveau jeu
|
||
* une nouvelle action
|
||
|
||
**Pourquoi :**
|
||
|
||
* Réduction des risques de régression
|
||
* Code stable sur le long terme
|
||
|
||
|
||
### 7. Clean Architecture (approche simplifiée)
|
||
|
||
**Application :**
|
||
|
||
* Le domaine ne dépend ni :
|
||
|
||
* de l’UI
|
||
* de la console
|
||
* du hasard
|
||
|
||
**Pourquoi :**
|
||
|
||
* Domaine réutilisable
|
||
* Structure claire
|
||
* Complément naturel de l’architecture hexagonale
|
||
|
||
|
||
### 8. Testabilité par design
|
||
|
||
**Application :**
|
||
|
||
* Interfaces partout
|
||
* Dépendances abstraites
|
||
* Console simulable
|
||
|
||
**Pourquoi :**
|
||
|
||
* Tests unitaires sans UI
|
||
* Scénarios déterministes
|
||
* Meilleure fiabilité du code
|
||
|
||
|
||
## 🏁 Conclusion
|
||
|
||
Même à l’échelle d’un mini-jeu console, cette architecture permet :
|
||
|
||
* un **code modulaire**
|
||
* une **évolution sans régression**
|
||
* une application concrète des principes **SOLID**
|
||
* une implémentation claire de l’**architecture hexagonale**
|
||
|
||
> *Ps:* On a donc utilisé un canon pour écraser une mouche, mais au moins, <br/> on sait comment fonctionne le canon !
|
||
|
||
---
|
||
|
||
# 📚 Annexe – Définitions
|
||
|
||
### Architecture Hexagonale (Ports & Adapters)
|
||
|
||
Architecture visant à isoler le cœur métier des détails techniques via des interfaces appelées ports, implémentées par des adapters.
|
||
|
||
### Single Responsibility Principle (SRP)
|
||
|
||
Une classe ne doit avoir qu’une seule raison de changer.
|
||
|
||
### Dependency Inversion Principle (DIP)
|
||
|
||
Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau, mais d’abstractions.
|
||
|
||
### Open / Closed Principle (OCP)
|
||
|
||
Une entité logicielle doit être ouverte à l’extension mais fermée à la modification.
|
||
|
||
### Factory Pattern
|
||
|
||
Pattern de création qui délègue l’instanciation d’objets à une classe dédiée.
|
||
|
||
### Strategy Pattern
|
||
|
||
Pattern comportemental qui encapsule des comportements interchangeables derrière une interface.
|
||
|
||
### Clean Architecture
|
||
|
||
Approche architecturale séparant le domaine métier des détails techniques. |