SOLID sans le dogme

Prérequis : cours 1.1 ; SRP et OCP, LSP, ISP et DIP.

Pourquoi

SOLID passe pour de la théorie d'entretien, mais chaque lettre prévient une douleur précise et vécue. L'astuce : les voir comme des symptômes à reconnaître, pas des règles à réciter.

Concepts

• S (responsabilité unique) : une classe = une raison de changer. OrderService qui facture + envoie des mails + génère des PDF = 3 raisons = 3 sources de conflits.
• O (ouvert/fermé) : extension sans modification — via polymorphisme/stratégies, pas via if qui s'allongent (chaque if ajouté est un risque de régression).
• L (substitution) : une sous-classe doit pouvoir remplacer sa mère partout sans surprise (pas d'exception inattendue, pas de précondition renforcée).
• I (ségrégation) : petites interfaces ciblées plutôt qu'une grosse qu'on implémente à moitié (méthodes qui lancent « non supporté » = violation visible).
• D (inversion) : dépendre d'abstractions, injectées (cf. DI). Le module métier ne connaît ni SQL ni HTTP.

Exemple : OCP par stratégie

// Au lieu de if/else qui s'allonge à chaque moyen de paiement :
const payers = { card: payCard, transfer: payTransfer, cash: payCash };
function pay(order) { return payers[order.method](order); }
// Nouveau moyen = nouvelle entrée, zéro modification du existant

Cas réel

Hiérarchie Employee → Manager qui lève « non applicable » sur clockIn() : violation LSP qui explose en prod le jour où le batch parcourt « tous les employés ». Refactor : composition (rôle Schedulable séparé) au lieu d'héritage.

Pièges

• SOLID appliqué aveuglément : 15 interfaces pour 3 classes = usine à gaz. Les principes servent le changement, pas la pureté.
• LSP violé « parce que ça marche dans nos cas » : ça casse dans le cas générique (batch, sérialisation, tests).
• Confondre DIP et DI : l'inversion est le principe, l'injection le mécanisme.

À retenir

Une raison de changer, extension sans modification, sous-classes substituables, petites interfaces, abstractions injectées — au service du changement réel.