Principes SOLID

En programmation orientée objet, SOLID est un acronyme mnémonique qui regroupe cinq principes de conception destinés à produire des architectures logicielles plus compréhensibles, flexibles et maintenables. Les principes sont un sous-ensemble de nombreux principes promus par l'ingénieur logiciel et instructeur américain Robert C. Martin.

Responsabilité unique (Single responsibility principle)

Une classe doit avoir une seule et unique raison de changer, ce qui signifie qu’une classe ne doit appartenir qu’à une seule tâche.

une classe, une fonction ou une méthode doit avoir une et une seule responsabilité. Plus de détails dans l'article dédié au principe de responsabilité unique en programmation.

Ouvert/fermé (Open/closed principle)

Les objets ou entités devraient être ouverts à l’extension mais fermés à la modification.

Tout module (package, classe, méthode) doit être ouvert aux extensions mais fermé aux modifications.

• ouvert aux extensions : le module peut être étendu pour proposer des comportements qui n'étaient pas prévus lors de sa création.
• fermé aux modifications : les extensions sont introduites sans modifier le code du module.
• utilisation de classes d'interface

Principe de Substitution de Liskov

Si q(x) est une propriété démontrable pour tout objet x de type T, alors q(y) est vraie pour tout objet y de type S tel que S est un sous-type de T.

La notion de sous-type telle que définie par Liskov et Wing est fondée sur la notion de substituabilité : si S est un sous-type de T, alors tout objet de type T peut être remplacé par un objet de type S sans altérer les propriétés désirables du programme concerné.

Le principe de Liskov impose des restrictions sur les signatures sur la définition des sous-types:

• Contravariance des arguments de méthode dans le sous-type.
• Covariance du type de retour dans le sous-type.

Aucune nouvelle exception ne doit être générée par la méthode du sous-type, sauf si celles-ci sont elles-mêmes des sous-types des exceptions levées par la méthode du supertype.

une instance de type T doit pouvoir être remplacée par une instance de type G, tel que G sous-type de T, sans que cela ne modifie la cohérence du programme

Ségrégation des interfaces (Interface segregation principle)

Un client ne doit jamais être forcé à installer une interface qu’il n’utilise pas et les clients ne doivent pas être forcés à dépendre de méthodes qu’ils n’utilisent pas.

préférer plusieurs interfaces spécifiques pour chaque client plutôt qu'une seule interface générale

Inversion des dépendances (Dependency inversion principle)

Les entités doivent dépendre des abstractions, pas des implémentations. Il indique que le module de haut niveau ne doit pas dépendre du module de bas niveau, mais qu’ils doivent dépendre des abstractions.

il faut dépendre des abstractions, pas des implémentations. Cela favorise la modularité, la flexibilité et la réutilisabilité en réduisant les dépendances directes entre les modules.