Principes SOLID
Cinq règles de structure pour du code orienté objet. Une classe fait une seule chose (responsabilité unique). On l'étend sans la modifier (ouvert ferme). Une sous-classe reste substituable à sa classe parente (Liskov). On découpe les interfaces trop larges plutôt que d'obliger une classe à implémenter des méthodes qu'elle n'utilise pas (ségrégation d'interface). Et on dépend d'abstractions, pas d'implémentations concrètes (inversion de dépendance). Formulées par Robert Martin au début des années 2000, elles décrivent une propriété du code : la capacité à changer une partie sans en casser une autre.
Forces
- Donne un vocabulaire commun pour dire pourquoi un fichier est trop gros, au lieu de le sentir sans pouvoir l'argumenter
- Vocabulaire stable depuis vingt ans et indépendant du langage : ce que tu apprends ici ne périme pas avec ton framework
Limites
- Appliqués mécaniquement, ils produisent une couche d'interfaces et d'abstractions qui coûte plus à lire que le code qu'elle protège
- Pensés pour l'orienté objet classique : la transposition à du code fonctionnel ou à des modules simples demande un effort de traduction
Pour qui
- Découper une codebase que ton agent n'arrive plus à modifier sans casser autre chose
- Mettre un mot précis sur un problème de structure pendant une revue de code