Qu'est-ce que SOLID ?
SOLID est un acronyme designant cinq principes de conception orientee objet formules par Robert C. Martin (Uncle Bob). Ces principes guident la création de logiciels maintenables, extensibles et robustes. Ils s'appliquent au-delà de la POO pure et influencent la conception de modules, services et architectures.
S - Single Responsibility Principle (SRP)
Une classe ne devrait avoir qu'une seule raison de changer. Chaque classe est responsable d'un seul aspect du système. Exemple : une classe UserService ne devrait pas gérer l'envoi d'emails et la persistence en base de données. Separez en UserService, EmailService et UserRepository. Ce principe s'applique aussi aux fonctions (une fonction fait une seule chose) et aux modules (un module gere un seul domaine).
O - Open/Closed Principle (OCP)
Les entités logicielles doivent être ouvertes à l'extension mais fermees à la modification. Ajoutez de nouveaux comportements en créant de nouvelles classes ou modules, pas en modifiant le code existant. Le polymorphisme et les interfaces permettent cela : une nouvelle forme geometrique implemente l'interface Shape sans modifier le code de calcul existant. Les plugins et les systèmes de middleware appliquent ce principe.
L - Liskov Substitution Principle (LSP)
Un objet d'une sous-classe doit pouvoir remplacer un objet de sa classe parente sans casser le programme. Les sous-classes doivent respecter le contrat de la classe parente : mêmes preconditions (ou plus faibles), mêmes postconditions (ou plus fortes). L'exemple classique de violation : un Carre heritant de Rectangle casse le LSP car modifier la largeur d'un carre modifie aussi la hauteur, ce qui n'est pas le comportement attendu d'un rectangle.
I - Interface Segregation Principle (ISP)
Les clients ne doivent pas être forces de dépendre d'interfaces qu'ils n'utilisent pas. Préférez plusieurs petites interfaces spécifiques à une grosse interface générale. Si une classe imprime et scanne, créez Printable et Scannable plutôt qu'une seule interface MultiFunctionDevice. Ce principe evite les implémentations vides et clarifie les dépendances réelles.
D - Dependency Inversion Principle (DIP)
Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau ; les deux doivent dépendre d'abstractions. Les détails (implémentations) dépendent des abstractions, pas l'inverse. Concrètement : un service métier dépend d'une interface Repository, pas directement de PostgresRepository. L'injection de dépendances (constructeur, framework DI) est le mécanisme d'implémentation le plus courant.