Cas pratiques SOLID Principles

Contexte Plusieurs classes héritent d’une classe BaseLogger contenant méthodes inutiles. Le Problème Certaines sous-classes implémentent des méthodes vides. Contraintes Refactorer vers composition plutôt qu’héritage excessif. Livrable attendu Une conception respectant LSP et ISP.

Contexte OrderService contient logique métier et requêtes SQL inline. Le Problème Violation du SRP et couplage fort à la base. Contraintes Extraire les requêtes dans un repository dédié. Livrable attendu Un découplage clair entre logique métier et persistence.

Contexte Une méthode processOrder contient validation, calcul, logging et envoi d’email. Le Problème Responsabilités multiples dans une seule méthode. Contraintes Découper en méthodes spécialisées ou services dédiés. Livrable attendu Un code plus lisible et respectant le Single Responsibility Principle.

Contexte Une classe Rectangle possède setWidth et setHeight. Une classe Square hérite et modifie le comportement. Le Problème Square casse les attentes du code utilisant Rectangle. Contraintes Refactorer la hiérarchie pour respecter substituabilité complète. Livrable attendu Une conception respectant le LSP sans effets inattendus.

Contexte Une classe UserService gère la création d’utilisateur, l’envoi d’email et la génération de rapport PDF. Le Problème La classe cumule plusieurs responsabilités non liées. Code actuel class UserService { createUser() {} sendWelcomeEmail() {} generateReport() {} } Contraintes Séparer les responsabilités en classes distinctes sans modifier l’API publique existante. Livrable attendu Un découpage clair respectant le principe de responsabilité unique.

Contexte Un service Payment instancie directement un client HTTP. Le Problème Impossible de mocker lors des tests. Code actuel this.client = new HttpClient(); Contraintes Refactorer pour injecter le client via constructeur. Livrable attendu Une classe facilement testable respectant DIP.

Contexte Un module calcule des réductions selon le type client via conditions multiples. Le Problème Chaque nouveau type nécessite modification du code existant. Code actuel if (type === "regular") {} else if (type === "vip") {} Contraintes Refactorer pour permettre ajout d’un nouveau type sans modifier la classe existante. Livrable attendu Une structure extensible respectant l’OCP.

Contexte Un service traite plusieurs types d’export (PDF, CSV, JSON). Le Problème Le traitement repose sur un switch central difficile à maintenir. Contraintes Remplacer par une approche polymorphique permettant extension sans modification. Livrable attendu Une solution respectant OCP et supprimant le switch.

Contexte Une interface Worker contient work() et eat(). Le Problème Un Robot implémente Worker mais n’utilise pas eat(). Code actuel class Robot implements Worker { work() {} eat() { throw Error("Not supported"); } } Contraintes Refactorer l’interface pour éviter l’implémentation inutile. Livrable attendu Une séparation d’interfaces respectant l’ISP.

Contexte Un service Notification dépend directement d'une classe EmailSender concrète. Le Problème Impossible de remplacer facilement EmailSender par SMS ou Mock. Code actuel class NotificationService { constructor() { this.sender = new EmailSender(); } } Contraintes Introduire une abstraction et injecter la dépendance. Livrable attendu Une implémentation respectant Dependency Inversion Principle.

Contexte Un service Payment dépend directement d’une librairie externe StripeLike. Le Problème Tout changement d’API casse le domaine métier. Contraintes Créer une abstraction interne PaymentGateway et encapsuler la librairie externe derrière cette interface. Livrable attendu Un découplage complet respectant DIP et protégeant le domaine.

Contexte Une classe Bird définit fly(). Une sous-classe Penguin lève une exception dans fly(). Le Problème Le code client suppose que tout Bird peut voler. Contraintes Refactorer la hiérarchie pour respecter Liskov Substitution Principle sans casser l’existant. Livrable attendu Une nouvelle modélisation correcte respectant substituabilité complète.

Contexte Une méthode exportData(format) contient plusieurs branches conditionnelles. Le Problème Chaque nouveau format nécessite modification interne. Contraintes Refactorer vers architecture extensible via stratégie ou registre dynamique. Livrable attendu Une solution permettant ajout de nouveaux formats sans modification du code existant.

Contexte Un module PricingService calcule les tarifs selon le type de produit. Le Problème Chaque nouveau type produit impose modification du switch central. Code actuel switch(product.type) { case "A": ... case "B": ... } Contraintes Refactorer vers une solution polymorphique ou basée sur stratégie injectable permettant extension sans modification du service principal. Livrable attendu Une architecture extensible conforme à l’OCP.

Contexte Plusieurs classes héritent d’une base complexe combinant logging, validation et persistence. Le Problème Les sous-classes héritent de comportements inutiles et violant LSP. Contraintes Refactorer vers composition avec injection des comportements nécessaires. Livrable attendu Une architecture flexible supprimant héritage excessif.

Contexte Une classe OrderManager gère validation métier, accès base de données, génération de facture PDF et envoi d’email. Le Problème Toute modification dans un aspect (ex: email) nécessite modification de la classe centrale, rendant les tests complexes. Contraintes Séparer clairement : - Validation métier - Persistence - Génération de facture - Notification Tout en conservant l’API publique existante. Livrable attendu Une nouvelle organisation modulaire respectant strictement le Single Responsibility Principle avec dépendances explicites.

Contexte Une interface IDataService contient : read(), write(), delete(), export(), validate(). Le Problème Certaines implémentations n’utilisent que read() et write(). Contraintes Segmenter l’interface en interfaces plus petites spécialisées tout en maintenant compatibilité ascendante. Livrable attendu Une architecture respectant Interface Segregation Principle avec interfaces ciblées.

Contexte InvoiceService calcule taxes, applique remises et génère format PDF ou JSON selon condition. Le Problème Responsabilités multiples et logique conditionnelle évolutive. Contraintes Refactorer pour isoler calcul métier, règles de remise et export via stratégies séparées. Livrable attendu Une structure modulaire respectant SRP et OCP.

Contexte Un service Order instancie Logger, Repository et EmailSender en interne. Le Problème Les tests unitaires nécessitent base réelle et envoi email réel. Contraintes Refactorer pour injecter toutes les dépendances via constructeur. Livrable attendu Une version testable via mocks respectant DIP.

Contexte Un module Reporting instancie directement SqlRepository. Le Problème Impossible de remplacer la base par MongoRepository sans modifier Reporting. Contraintes Introduire une abstraction Repository et injecter l’implémentation via constructeur ou conteneur simple. Livrable attendu Une architecture découplée respectant Dependency Inversion Principle.

Contexte Une application doit permettre d’ajouter dynamiquement des extensions métier. Le Problème L’implémentation actuelle nécessite modification du noyau à chaque ajout. Contraintes Concevoir un noyau stable dépendant uniquement d’abstractions, avec plugins injectés dynamiquement. Livrable attendu Une architecture démontrant respect combiné de SRP, OCP, ISP et DIP dans un système extensible.

Contexte Deux modules CoreService et ReportingService s’importent mutuellement. Le Problème Couplage bidirectionnel rendant tests et maintenance difficiles. Contraintes Introduire des abstractions communes ou événements pour supprimer dépendances croisées. Livrable attendu Une architecture découplée respectant Dependency Inversion Principle.

Contexte Une classe ApplicationService orchestre logique métier, accès base, appels HTTP externes et logging. Le Problème La classe instancie directement SqlRepository, HttpClient et Logger et mélange responsabilités. Code actuel class ApplicationService { constructor() { this.repo = new SqlRepository(); this.http = new HttpClient(); this.logger = new Logger(); } } Contraintes Séparer responsabilités métier et techniques, introduire abstractions et injection de dépendances. Livrable attendu Une architecture respectant SRP et DIP avec dépendances inversées et modules clairement isolés.

Contexte Un système Workflow utilise une hiérarchie de classes State mal définie. Le Problème Certaines transitions modifient des comportements attendus dans le parent. Contraintes Redéfinir les contrats d’interface et assurer cohérence comportementale complète. Livrable attendu Une modélisation robuste respectant LSP et SRP dans un contexte de workflow avancé.

Contexte Une interface ISystemService expose 12 méthodes utilisées par 8 implémentations différentes. Le Problème Chaque implémentation laisse plusieurs méthodes vides ou non supportées. Contraintes Segmenter l’interface en sous-interfaces cohérentes sans casser compatibilité ascendante. Livrable attendu Un découpage d’interfaces respectant Interface Segregation Principle avec migration progressive.

Contexte Un moteur de calcul applique différentes règles métiers selon type d’événement. Le Problème Un switch central massif est modifié à chaque nouvelle règle. Contraintes Mettre en place un registre dynamique permettant d’enregistrer de nouvelles règles sans modification du moteur. Livrable attendu Une architecture extensible respectant strictement Open/Closed Principle.

Contexte Un module DiscountEngine contient logique conditionnelle, dépendances concrètes et héritage fragile. Le Problème Ajout d’un nouveau type de remise casse plusieurs sous-classes existantes. Contraintes Repenser entièrement la structure pour isoler responsabilités, introduire stratégies et garantir substituabilité. Livrable attendu Une architecture propre respectant les trois principes simultanément.

Contexte Une hiérarchie Document -> EditableDocument -> ReadOnlyDocument est utilisée. Le Problème ReadOnlyDocument surcharge save() en lançant une exception, cassant le contrat parent. Contraintes Refactorer la hiérarchie pour garantir substituabilité complète sans exception comportementale. Livrable attendu Une modélisation respectant LSP avec séparation claire des capacités modifiables et non modifiables.

Contexte Un service Payment dépend directement d'une API externe évolutive. Le Problème Les changements d’API obligent modifications multiples dans le domaine. Contraintes Introduire une abstraction interne Gateway et mapper complet protégeant le domaine. Livrable attendu Une architecture isolant totalement la dépendance externe via DIP.

Contexte Le code dépend directement de frameworks (ORM, HTTP, logger) dans toutes les couches. Le Problème Impossible de tester le domaine sans infrastructure réelle. Contraintes Introduire interfaces internes et isoler totalement le domaine des frameworks. Livrable attendu Une architecture respectant strictement Dependency Inversion et favorisant testabilité maximale.