| S | Single Responsibility Principle (SRP) | Une classe ou un module doit avoir une seule et unique raison d’être modifié. | Si un changement de la DB et un changement de la logique de calcul affectent la même classe, divisez cette classe. | Créer des classes “God Objects” (objets divins) qui gèrent des dizaines de responsabilités différentes. |
| O | Open/Closed Principle (OCP) | Les entités logicielles (classes, modules) doivent être ouvertes à l’extension, mais fermées à la modification. | Utiliser l’héritage ou l’injection de dépendances pour ajouter de nouvelles fonctionnalités sans toucher au code existant et testé. | Modifier directement les classes de base et forcer la re-validation de tout code dépendant. |
| L | Liskov Substitution Principle (LSP) | Les objets d’un programme doivent pouvoir être remplacés par des instances de leurs sous-types sans altérer la justesse du programme. | Assurez-vous que les classes dérivées respectent le contrat de la classe de base (les méthodes héritées ne doivent pas casser la logique attendue). | Créer une sous-classe dont les méthodes lèvent des exceptions inattendues ou ne font rien lorsque l’on attend une action. |
| I | Interface Segregation Principle (ISP) | Les clients ne doivent pas être forcés de dépendre d’interfaces qu’ils n’utilisent pas. | Créer des interfaces petites et spécifiques (interfaces granulaires) plutôt qu’une seule interface massive. | Définir une interface Monolithe avec 20 méthodes, forçant toutes les classes à implémenter des méthodes dont elles n’ont pas besoin. |
| D | Dependency Inversion Principle (DIP) | Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Tous deux devraient dépendre d’abstractions (interfaces). | Utiliser l’Injection de Dépendances (DI) pour lier les abstractions aux implémentations au moment de l’exécution. | Lier directement la logique métier (haut niveau) à une implémentation concrète (ex: un driver de DB spécifique), rendant le remplacement impossible. |
