Cas pratiques Design Patterns

Contexte Une classe Order change de comportement selon son statut (Pending, Paid, Shipped). Le Problème Le code utilise des if/else répétitifs selon l’état. Contraintes Implémenter un State Pattern où chaque état encapsule son comportement. Livrable attendu Une structure supprimant les conditions multiples au profit de classes d’état distinctes.

Contexte Plusieurs classes héritent d’une classe BaseVehicle avec de nombreuses méthodes inutilisées. Le Problème L’héritage crée rigidité et complexité. Contraintes Refactorer vers une approche basée sur composition (injection de comportements). Livrable attendu Une structure utilisant objets composables au lieu d’héritage massif.

Contexte Un module Order doit notifier plusieurs modules (Email, SMS) lors d’un changement de statut. Le Problème Le code appelle directement chaque module : sendEmail(); sendSMS(); Contraintes Implémenter un Observer Pattern permettant d’enregistrer dynamiquement les abonnés. Livrable attendu Une classe Subject et plusieurs Observers découplés.

Contexte Un module Database est instancié plusieurs fois dans l’application. Le Problème Chaque instanciation ouvre une nouvelle connexion. Code actuel const db1 = new Database(); const db2 = new Database(); Contraintes Modifier la classe pour garantir une seule instance partagée. Livrable attendu Une implémentation simple du Singleton Pattern empêchant les instanciations multiples.

Contexte Un objet ServerConfig possède 10 paramètres optionnels. Le Problème Le constructeur devient illisible : new ServerConfig(host, port, ssl, timeout, retries, cache, ...); Contraintes Introduire un Builder permettant configuration progressive et lisible. Livrable attendu Une implémentation simple du Builder Pattern améliorant la lisibilité.

Contexte Une fonction calcule des frais selon le type de paiement. Le Problème Le code utilise plusieurs if/else : if (method === "card") { ... } else if (method === "paypal") { ... } else if (method === "crypto") { ... } Contraintes Remplacer cette logique par des stratégies indépendantes sélectionnées dynamiquement. Livrable attendu Une implémentation simple du Strategy Pattern permettant l’ajout d’un nouveau mode sans modifier la fonction principale.

Contexte Un service interne attend une méthode pay(amount), mais une API externe expose makePayment(sum). Le Problème L’interface est incompatible. Contraintes Créer un Adapter traduisant l’interface externe vers l’interface attendue. Livrable attendu Une classe Adapter permettant d’utiliser l’API externe sans modifier le code client.

Contexte Un module accède directement à une API distante lente. Le Problème Chaque appel provoque un délai important. Contraintes Introduire un Proxy ajoutant cache simple avant délégation à l’API réelle. Livrable attendu Une classe Proxy encapsulant logique de cache et délégation.

Contexte Une application crée différents types d’utilisateurs (Admin, Customer, Guest) avec une logique conditionnelle répétée. Le Problème Le code actuel utilise des if/else multiples : function createUser(type) { if (type === "admin") return new Admin(); if (type === "customer") return new Customer(); if (type === "guest") return new Guest(); } Contraintes Remplacer cette logique par une Factory centralisée évitant la duplication et facilitant l’ajout d’un nouveau type. Livrable attendu Une implémentation simple du Factory Pattern supprimant les conditions répétitives.

Contexte Un module doit appeler plusieurs sous-modules (Auth, Logger, Validator) avant traitement. Le Problème Le code client doit gérer tous les appels manuellement. Contraintes Créer une façade unifiée simplifiant l’interaction avec ces sous-systèmes. Livrable attendu Une classe Facade centralisant les appels internes.

Contexte Un Builder permet de configurer un objet ServerConfig. Le Problème Le builder actuel permet de construire un objet incomplet ou invalide. Code actuel builder.setPort(3000); const config = builder.build(); Contraintes Ajouter validation interne obligatoire avant build() et empêcher création si paramètres essentiels manquants. Livrable attendu Un Builder robuste garantissant cohérence de l’objet construit.

Contexte Un Subject enregistre des observers sans jamais les supprimer. Le Problème Les observers s’accumulent et provoquent une fuite mémoire. Code actuel subject.subscribe(listener); Contraintes Ajouter un mécanisme unsubscribe et garantir suppression propre des observers inutilisés. Livrable attendu Une implémentation Observer robuste évitant toute accumulation indésirable.

Contexte Une classe Order change d’état mais certaines transitions ne sont pas validées. Le Problème Une commande peut passer directement de Pending à Delivered. Contraintes Renforcer le State Pattern pour contrôler strictement transitions autorisées. Livrable attendu Une implémentation garantissant validité des transitions d’état.

Contexte Plusieurs modules communiquent directement entre eux. Le Problème Chaque module importe les autres, créant un couplage fort. Contraintes Introduire un Mediator central gérant les interactions. Livrable attendu Une implémentation Mediator supprimant toute dépendance directe entre modules.

Contexte Un module Payment dépend directement d’une API externe complexe. Le Problème Toute modification de l’API externe casse le système interne. Contraintes Créer un Adapter encapsulant transformation des données et gestion des erreurs externes. Livrable attendu Une couche d’adaptation protégeant complètement le domaine interne.

Contexte Un service sensible doit vérifier les permissions avant exécution. Le Problème Les vérifications sont répétées dans chaque méthode. Contraintes Créer un Proxy ajoutant vérification d’accès avant délégation à l’objet réel. Livrable attendu Une implémentation Proxy centralisant la sécurité sans modifier la classe cible.

Contexte Une application génère des composants UI pour Web et Mobile. Le Problème Le code utilise des conditions imbriquées pour créer ButtonWeb, ButtonMobile, InputWeb, InputMobile. Code actuel if (platform === "web") { button = new ButtonWeb(); } else { button = new ButtonMobile(); } Contraintes Remplacer cette logique par une Abstract Factory permettant de créer des familles cohérentes de composants sans condition explicite. Livrable attendu Une implémentation complète d’Abstract Factory supprimant toute condition liée à la plateforme.

Contexte Un service Email ajoute options logging et encryption via héritage multiple. Le Problème Chaque combinaison nécessite une nouvelle classe. Contraintes Remplacer l’héritage par des Decorators dynamiques empilables. Livrable attendu Une implémentation permettant d’ajouter logging et encryption sans modifier la classe de base.

Contexte Plusieurs classes suivent le même workflow avec petites variations. Le Problème Le code est dupliqué avec différences minimes. Contraintes Créer une classe abstraite définissant le squelette d’algorithme et déléguer les variations. Livrable attendu Une implémentation Template Method réduisant la duplication.

Contexte Un module exécute différentes actions selon une commande texte. Le Problème Le code contient un switch massif : switch(action) { case "CREATE": ... case "DELETE": ... case "UPDATE": ... } Contraintes Remplacer cette structure par un Command Pattern avec classes dédiées et exécution dynamique. Livrable attendu Une implémentation permettant d’ajouter une commande sans modifier le code central.

Contexte Un système applique plusieurs validations successives sur une requête. Le Problème Les validations sont codées séquentiellement et difficilement reconfigurables. Contraintes Créer une chaîne de handlers dynamiques pouvant être ordonnée ou modifiée sans changer le cœur. Livrable attendu Une implémentation flexible du Chain of Responsibility.

Contexte Un module gère simultanément commandes d’écriture et requêtes complexes de lecture. Le Problème Les performances chutent et le code devient difficile à maintenir. Contraintes Séparer modèle de commande (write model) et modèle de lecture (read model) avec structures distinctes. Livrable attendu Une architecture interne séparant clairement responsabilités lecture et écriture.

Contexte Une application multi-plateforme (Web, Mobile) utilise une Abstract Factory pour créer ses composants UI. Le Problème Le code client instancie directement la factory concrète : const factory = new WebFactory(); const button = factory.createButton(); Ce couplage empêche toute inversion de dépendance et rend les tests difficiles. Contraintes Refactorer le système pour injecter la factory via abstraction (interface ou contrat). Le code client ne doit plus dépendre d’implémentation concrète. Livrable attendu Une architecture respectant DIP où la sélection de la factory est externalisée.

Contexte Un Decorator modifie radicalement le comportement d'une classe EmailService. Le Problème Certaines méthodes du Decorator ne respectent plus le contrat de l’objet décoré. Contraintes Refactorer le Decorator pour garantir substituabilité complète et respect du contrat initial. Livrable attendu Une implémentation conforme au principe Liskov Substitution.

Contexte Un Subject notifie plusieurs Observers synchrones. Le Problème Si un observer est lent, tous les autres sont bloqués. Code actuel observers.forEach(o => o.update(data)); Contraintes Introduire une notification asynchrone isolant les échecs et lenteurs. Livrable attendu Un Observer Pattern résilient empêchant propagation des blocages.

Contexte Un système gère catégories et sous-catégories imbriquées. Le Problème La gestion récursive est codée manuellement et dupliquée. Contraintes Implémenter un Composite Pattern permettant traitement uniforme des nœuds simples et composites. Livrable attendu Une structure arborescente manipulable via interface commune.

Contexte Un workflow métier contient 8 états et transitions conditionnelles. Le Problème Les transitions sont gérées via multiples if/else dispersés. Contraintes Concevoir une State Machine explicite avec table de transitions valide et gestion des erreurs d’état. Livrable attendu Une implémentation centralisée garantissant cohérence et traçabilité des transitions.

Contexte Une application supporte plusieurs modes de paiement codés en dur. Le Problème Chaque nouveau mode nécessite modification du code central. Contraintes Concevoir une architecture de plugins dynamiques permettant d’enregistrer un nouveau mode sans modifier le cœur. Livrable attendu Un système extensible basé sur enregistrement dynamique de stratégies.

Contexte Plusieurs modules communiquent via imports directs croisés. Le Problème Le couplage rend l’évolution dangereuse. Contraintes Concevoir un Mediator central basé sur un Event Bus interne permettant communication découplée et extensible. Livrable attendu Une architecture supprimant toute dépendance directe entre modules.

Contexte Un Singleton est utilisé pour gérer une connexion base de données. Le Problème Dans un environnement multi-thread ou worker, plusieurs instances sont créées simultanément. Code actuel class Database { constructor() {} } Contraintes Garantir unicité même en cas d’accès concurrent, et empêcher toute instanciation directe. Livrable attendu Une implémentation robuste empêchant double instanciation concurrente.