DecouverteDev/Correction

🧠 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#.
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
❌ 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,
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.