# 🧠 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:*<br/>
> On a donc utilisé un canon pour écraser une mouche, mais au moins, on sait comment fonctionne le canon!<br/>
> Et oui, c'est excessif pour un jeu en console. Non, on ne regrette rien. L'apprentissage n'a pas de prix (mais a beaucoup de classes).

---

# 📚 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.