mise à jour

Author: CodeWithFrenchy

_drafts/2025-09-22-utilisation-design-patterns.md

@@ -130,7 +130,7 @@ Le pattern **Strategy** permet de définir une famille d’algorithmes, de les e
 
 L’un des grands bénéfices de ce pattern est qu’il **respecte le principe d’ouverture/fermeture** (*Open/Closed Principle*) : votre code est **ouvert à l’extension**, mais **fermé à la modification**. Autrement dit, si un jour un nouveau mode de calcul doit être ajouté (par exemple une livraison par drone 🛸), pas besoin de toucher au calculateur existant : on ajoute une nouvelle stratégie, et c’est tout.
 
-C’est une alternative élégante et maintenable aux chaînes de `if/else` ou de `switch` sur des enums, qui violent souvent ce principe (car chaque ajout nécessite de modifier le bloc conditionnel existant). Avec le patron Strategy, on **étend** le comportement en ajoutant une nouvelle classe, plutôt qu’en modifiant du code existant — ce qui réduit les risques de régression.
+C’est une alternative élégante et maintenable aux chaînes de `if/else` ou de `switch` sur des `enums`, qui violent souvent ce principe (car chaque ajout nécessite de modifier le bloc conditionnel existant). Avec le patron Strategy, on **étend** le comportement en ajoutant une nouvelle classe, plutôt qu’en modifiant du code existant — ce qui réduit les risques de régression.
 
 
 
@@ -213,7 +213,7 @@ __Quand l’utiliser 🟢 :__ Quand vous avez plusieurs variantes algorithmiques
 
 __À éviter 🔴 :__ Si vos variantes d’algorithmes sont très simples ou qu’il n’y en a qu’une ou deux peu susceptibles d’évoluer, le pattern peut être overkill. Aussi, n’introduisez pas une stratégie juste pour éviter un `if` unique — le remède serait pire que le mal. Enfin, veillez à ce que les stratégies partagent bien la même interface commune et puissent réellement varier indépendamment du reste : si elles finissent par dépendre fortement du contexte externe, le gain de découplage diminue.
 
-__Intégration .NET 👩‍💻 :__ On peut tirer parti de l’IoC container pour gérer les stratégies. Par exemple, vous pourriez __injecter toutes les implémentations__ d’une interface et sélectionner la bonne à l’exécution (via un dictionnaire de stratégies, ou en taguant chaque implémentation d’un attribut \[Strategy("Nom")]). Une autre approche consiste à enregistrer une Factory (comme vue plus haut) dans l’IoC qui retourne la stratégie voulue. .NET Core facilite même cela avec les *Named Options* ou en combinant avec le pattern __Policy__. Bref, le patron Strategy se marie bien avec l’injection de dépendances pour éviter de faire de `new` manuellement : on peut demander au container de résoudre la stratégie dont on a besoin, ce qui simplifie le remplacement (ex: injection d’une fausse stratégie en tests unitaires).
+__Intégration .NET 👩‍💻 :__ On peut tirer parti de l’IoC container pour gérer les stratégies. Par exemple, vous pourriez __injecter toutes les implémentations__ d’une interface et sélectionner la bonne à l’exécution (via un dictionnaire de stratégies, ou en taguant chaque implémentation d’un `attribut` \ `[Strategy("Nom")])`. Une autre approche consiste à enregistrer une Factory (comme vue plus haut) dans l’IoC qui retourne la stratégie voulue. .NET Core facilite même cela avec les *Named Options* ou en combinant avec le pattern __Policy__. Bref, le patron Strategy se marie bien avec l’injection de dépendances pour éviter de faire de `new` manuellement : on peut demander au container de résoudre la stratégie dont on a besoin, ce qui simplifie le remplacement (ex: injection d’une fausse stratégie en tests unitaires).
 
 ## Decorator : Ajouter des fonctionnalités à la volée (comme une cache sur vos services)