SOLID signifie :

- Single-Responsability Principle : une classe n’a qu’une seule responsabilité.
- Open/Closed Principle : une classe doit être ouverte à l’extension mais pas l’inverse (Disponible a l’héritage) (pas dispo pour changer les attribut -> privé)
- Liskov Substitution Principle : les objets d’un programme doivent pouvoir être remplacés par des instances de leurs sous-types sans changer les classes du programme.
- Interface Segregation Principle : il vaut mieux avoir plusieurs interfaces spécifiques qu’une unique interface générique.
- Dependency Inversion Principle : Il faut faire en sorte que les classes de haut niveau soient indépendantes des classes de bas niveau.

Single Responsability Principle :

Ce principe essaie de refléter une notion de base de la programmation : La responsabilité. Ce principe dit que chaque classe n’a qu’une et une seule responsabilité. Réalisé un code en respectant ce principe permet d’avoir un code plus stable que l’on aura moins besoin de changer au fur et a mesure que votre code avance.

Open/Closed Principle

Le code que vous allez réaliser, dès lors qu’il est testé et que tout fonctionne vous n’y toucherez plus (principe fermé, moyen mnémotechnique fermé au modification). Il l’est par exemple grâce des attributs mit en privé. C’est le principe de base pour l’ouvert/fermé. Par contre votre classe doit être ouverte à l’extension, c’est-à-dire, qu’une classe ne doit pas dépendre d’une classe concrète, mais plutôt abstraite. L’open closed principle est la base même de la conception orientée objet et permet d’avoir un meilleur niveau de réutilisabilité et maintenabilité.

Liskov Substitution Principle :

L’objectif de ce principe est d’avoir la possibilité de remplacés une instance de la classe par la classe elle-même et que la personne qui l’utilise n’ait pas de problèmes. Il faut que la sous classe ait exactement les mêmes propriétés que la classe au-dessus et du coup faire attention aux exceptions que l’on va lever dans la classe mère qui ne seront pas disponible dans la classe qui hérite par exemple.

Interface Segregation Principle :

L’objectif de ce principe est d’essayer de régir plusieurs interfaces, c’est-à-dire de créer une interface spécifique à chaque méthode. Attention à ne pas commettre l’erreur d’en créer trop. Toutes les interfaces qui vont être crées doivent avoir un intérêt pour l’utilisateur. Ce principe privilégie du coup plusieurs interface plutôt qu’une qui soit trop généraliste.

Dependency Inversion Principle :

Ce principe va permettre que les classes de haut soit indépendantes des classes de bas niveaux. En retournant le problème les classes de hauts niveaux ont une forte dépendance sur les classes de bas niveaux et si on change quelque chose dans ses dernières le code devra être modifié. C'est pourquoi on cherche à obtenir l'inverse en appliquant ce principe.