🎓 Design Pattern Factory & Principes SOLID

🏭 LE DESIGN PATTERN FACTORY

📖 Définition

Le Factory Method Pattern est un patron de conception qui délègue la création d'objets à une interface spécialisée. Concrètement :

Le framework définit l'interface Factory générique (le "contrat")
L'application implémente cette interface pour créer ses classes spécifiques

Au lieu d'écrire new ObjetConcret() partout dans ton code, tu appelles factory.createPizza() !

🎯 Pourquoi c'est utile ?

Le Factory permet au framework de créer et manipuler des classes qu'il ne connaît pas encore, sans jamais modifier son propre code. C'est la magie de l'extensibilité !

Avantages clés :

✅ Ajouter de nouveaux types d'objets sans toucher au code existant
✅ Le framework reste générique et réutilisable
✅ Séparation claire entre création et utilisation

💡 Exemple mémorable : La Pizzeria

Imagine une pizzeria (le framework) :

🍕 PIZZERIA (Framework)
├─ Sait cuire des pizzas
├─ Sait les emballer
└─ Ne connaît PAS les recettes spécifiques

📋 Interface PizzaFactory
└─ createPizza() : Pizza

🇮🇹 Franchise Italienne (Application)
└─ Implémente PizzaFactory
    └─ createPizza() → Margherita, Quattro Formaggi...

🇺🇸 Franchise Américaine (Application)
└─ Implémente PizzaFactory
    └─ createPizza() → Pepperoni, Hawaiian...

La pizzeria appelle simplement factory.createPizza() sans connaître les recettes concrètes. Chaque franchise produit ses pizzas locales !

🎯 LES PRINCIPES SOLID

⚠️ Important : Ce sont des GUIDELINES (lignes directrices), PAS DES LOIS ABSOLUES !

S - Single Responsibility Principle 🎯

Une classe = une seule raison de changer

❌ Mauvais : Classe "Couteau Suisse"
└─ Fait tout, mais mal

✅ Bon : Classes spécialisées
├─ Classe Couteau
├─ Classe Tournevis
└─ Classe Ouvre-bouteille

O - Open/Closed Principle 🔓🔒

Ouvert à l'extension, fermé à la modification

✅ Ajoute des fonctionnalités par héritage ou interfaces
❌ Ne modifie pas le code existant qui fonctionne

L - Liskov Substitution Principle 🔄

Une sous-classe doit pouvoir remplacer sa classe parent sans que le programme le sache

# Si tu as une classe Oiseau
class Oiseau:
    def voler(self):
        pass

# Un Pingouin ne devrait PAS hériter d'Oiseau
# car il ne peut pas voler !

I - Interface Segregation Principle ✂️

Petites interfaces spécifiques > grosse interface générale

❌ Interface "Employé" avec 50 méthodes
   └─ Un stagiaire doit implémenter "signerContratCEO()" ?

✅ Interfaces ciblées
   ├─ Interface "Travailleur"
   ├─ Interface "Manager"
   └─ Interface "Dirigeant"

D - Dependency Inversion Principle 🔌

Dépends d'abstractions (interfaces), pas de classes concrètes

Les abstractions ne dépendent pas des détails, ce sont les détails qui dépendent des abstractions.

# ❌ Mauvais
class Application:
    def __init__(self):
        self.db = MySQLDatabase()  # Dépendance concrète

# ✅ Bon
class Application:
    def __init__(self, db: Database):  # Dépendance abstraite
        self.db = db

🎯 Objectifs globaux de SOLID

Les principes SOLID visent à créer un code :

🧹 Maintenable : Facile à comprendre et modifier
🚀 Extensible : Ajouter des fonctionnalités sans tout casser
🧪 Testable : Facile à tester unitairement
🔗 Faiblement couplé : Les composants sont indépendants
🎯 Fortement cohésif : Chaque classe a un objectif clair

Résultat : Éviter la dette technique et garder un code sain sur le long terme !

🎓 En résumé

Factory = Déléguer la création d'objets pour rendre le code extensible
SOLID = 5 principes pour écrire du code propre et maintenable
Ce sont des outils, pas des dogmes : utilise-les avec discernement ! 💪