Ainsi l'acronyme signifie:
S pour Single responsibility principle, signifiant qu'une entité ne doit avoir qu'une seul préoccupation et donc ne répondre qu'à une problématique. Cela suit le principe d'analyse en décomposition permettant de dissocier chacun des éléments du système. Généralement ce principe s'applique en premier lieu aux classes (en POO) cependant il est largement admis qu'il est généralisable en l'adaptant au niveau d'abstraction considéré. Ainsi, on retrouvera la même logique sur des composants mais aussi dans les approches de programmation fonctionnelle.
O pour Open/closed principle. Ce principe est à considérer dans la continuité du principe précédent. C'est à dire que si une entité ne considère qu'un seul problème, afin de garantir cette propriété, elle ne doit pas permettre sa modification sinon, soit elle ne répond plus au problème initial soit elle répond a plus que celui ci. Par contre afin de permettre la composition et l'agrégation des fonctions, une entité doit permettre et même faciliter son extension. ainsi en POO on utilisera les mécanismes bien connu d'héritage ou d'encapsulation permettant de compléter ou d'associer des comportements aux sein d'entité dont c'est justement l'unique rôle.
L pour Liskov principle. Rarement violé ce principe impose que les sous types d'une entité doivent continuer à respecter le contrat de base de celle ci et ne pas la transformer, seulement l'étendre. Ainsi grâce à ce principe, la substitution d'une entité par l'un de ses sous types est transparent.
I pour Interface segregation principle. Rejoignant une nouvelle fois le premier principe, celui ci nous pousse à favoriser la construction d'interfaces multiples mais individuelle plutôt qu'une interface agrégeant l'ensemble des contrats à réaliser. Ainsi la maintenabilité s'en trouve augmenté et grâce au précédent principe, une entité bien que potentiellement défaillante selon une interface peut rester fonctionnelle selon une autre (sinon toutes l'auraient été)
D pour Dependency inversion principle est la aussi la continuité du précédemment principe en considérant que les dépendances, si elles sont construite sur les entité les plus abstraites, permettent plus de souplesse dans la construction logiciel et facilite la réorganisation et la substitution en vertue du principe de Liskov. Poussé à son extrême, ce principe nous amènera alors naturellement vers les frameworks permettant l'inversion de contrôle et l'injection de dépendances
Si tout cela n'est pas encore très clair, je vous invite à lire cette petite page qui résume parfaitement SOLID dans la vie quotidienne
Références
[1] http://blog.xebia.fr/2011/07/18/les-principes-solid[2] http://www.arolla.fr/blog/2017/02/principes-solid-vie-de-jours/
Aucun commentaire:
Enregistrer un commentaire