I. IntroductionSOLID est l'acronyme de cinq principes de base (Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle et Dependency Inversion Principle) que l'on peut appliquer au développement objet.
I - B. Couplage=--------Le couplage est une métrique qui mesure l'interconnexion des modules. Deux modules sont dit couplés si une modification d'un de ces modules demande une modification dans l'autre.
I - C. Encapsulation :+++++++L'idée derrière l'encapsulation est d'intégrer à un objet tous les éléments nécessaires à son fonctionnement, que ce soit des fonctions ou des données.
Le corolaire est qu'un objet devrait (et non pas doit, comme c'est souvent expliqué) masquer la cuisine interne de la classe, pour exposer une interface propre, de façon à ce que ses clients puissent manipuler l'objet et ses données sans avoir à connaitre le fonctionnement interne de l'objet.
II. Responsabilité unique (SRP: Single Responsibility Principle)Le principe de responsabilité unique, est qu'une classe donnée ne doit avoir qu'une seule responsabilité, et, par conséquent, qu'elle ne doit avoir qu'une seule raison de changer.
Les avantages de cette approche sont les suivants:
-Diminution de la complexité du code
-Augmentation de la lisibilité de la classe
-Meilleure encapsulation, et meilleure cohésion, les responsabilités étant regroupées
pour l’appliquer il faut Analyser et regrouper des méthodes du code puis en sortir des classes
II. Ouvert/fermé (OCP: Open/closed Principle)
-Les modules qui se conforment au principe ouvert/ferme ont deux attributs principaux. 1 - Ils sont "ouverts pour l'extension". Cela signifie que le comportement du module peut être étendu, que l'on peut faire se comporter ce module de façons nouvelles et différentes si les exigences de l'application sont modifiées, (hériter de la classe d'origine)
2 - Ils sont "Fermés à la modification". Le code source d'un tel module ne peut pas être modifié. Personne n'est autorisé à y apporter des modifications.«
Voir Exemple
III. Substitution de Liskov (LSP: Liskov Substitution Principle)
-Les sous-types doivent être remplaçables par leur type de base SANS CAST.
Principe de Polymorphisme on POO.
Voir Exemple
IV. Séparation des Interfaces (ISP: Interface Segregation Principle)
-Les clients ne doivent pas être forcés de dépendre d'interfaces qu'ils n'utilisent pas.
Les interfaces doit être le moins compliquée.
Modèle ISP
V.Inversion des dépendances (DIP: Dependency Inversion Principle)
Les architectures classiques ne permettent pas la réutilisation des modules "métier"
Dans la plupart des applications, les modules de haut niveau (ceux qui portent la logique fonctionnelle de l'application ou les aspects "métier") sont construits directement sur les modules de bas niveau (par exemple les librairies graphiques ou de communication)
Les modules de haut niveau doivent être modifiés lorsque les modules de bas niveau sont modifiés.
Selon le principe d'inversion des dépendances
, la relation de dépendance doit être inversée : les modules de bas niveau doivent se conformer à des interfaces définies et utilisées par les modules de haut niveau.
Vers des Framework métier ?
Ce principe conduit à des applications dans lesquelles la logique "métier" est parfaitement réutilisable. Cette partie métier forme une sorte de "framework", qui permet de développer une même application dans des contextes techniques différents.(sfeir Tools bon exemple, edition EML )