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 creation de logiciels maintenables, extensibles et robustes. Ils s'appliquent au-dela 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 systeme. Exemple : une classe UserService ne devrait pas gerer l'envoi d'emails et la persistence en base de donnees. 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 entites logicielles doivent etre ouvertes a l'extension mais fermees a la modification. Ajoutez de nouveaux comportements en creant 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 systemes 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 : memes preconditions (ou plus faibles), memes 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 etre forces de dependre d'interfaces qu'ils n'utilisent pas. Preferez plusieurs petites interfaces specifiques a une grosse interface generale. Si une classe imprime et scanne, creez Printable et Scannable plutot qu'une seule interface MultiFunctionDevice. Ce principe evite les implementations vides et clarifie les dependances reelles.
D - Dependency Inversion Principle (DIP)
Les modules de haut niveau ne doivent pas dependre des modules de bas niveau ; les deux doivent dependre d'abstractions. Les details (implementations) dependent des abstractions, pas l'inverse. Concretement : un service metier depend d'une interface Repository, pas directement de PostgresRepository. L'injection de dependances (constructeur, framework DI) est le mecanisme d'implementation le plus courant.