Rvision et principes SOLID Architecture dapplication Hugo
St-Louis
Page 2
Page 3
PollEv.com
Page 4
Dont forget: You can copy-paste this slide into other
presentations, and move or resize the poll. Poll: Pourquoi utiliser
un fichier de configur...
Page 5
Dont forget: You can copy-paste this slide into other
presentations, and move or resize the poll. Poll: Pour une
application multilingue, qu'est...
Page 6
Dont forget: You can copy-paste this slide into other
presentations, and move or resize the poll. Poll: L'objectif de ce
cours est.....
Page 7
Introduction aux principes SOLID Architecture dapplication Hugo
St-Louis
Page 8
Introduction aux principes SOLID Architecture dapplication Hugo
St-Louis
Page 9
Plan Introduction Principes SOLID Conclusion
Page 10
Introduction Mtrique dun bon programme objet par rapport sa
conception Cohsion: Une classe => une tche Couplage: Liens entre
les objets pour former un tout. Encapsulation: Rendre invisible
limplmentation
Page 11
SOLID SOLID 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
dveloppement objet. Bas sur la mthodologie AGILE, tels que dcrits
dans le livre de Robert Martin, Agile Software Development,
Principles, Patterns, and PracticesAgile Software Development,
Principles, Patterns, and Practices
Page 12
Responsabilit unique (SRP: Single Responsibility Principle)
Dfinition:"Si une classe a plus d'une responsabilit, alors ces
responsabilits deviennent couples. Des modifications apportes l'une
des responsabilits peuvent porter atteinte ou inhiber la capacit de
la classe de remplir les autres. Ce genre de couplage amne des
architectures fragiles qui dysfonctionnent de faon inattendues
lorsqu'elles sont modifies." -- Robert C. Martin
Page 13
Responsabilit unique (SRP: Single Responsibility
Principle)
Page 14
Le principe de responsabilit unique, rduit sa plus simple
expression, est qu'une classe donne ne doit avoir qu'une seule
responsabilit, et, par consquent, qu'elle ne doit avoir qu'une
seule raison de changer.
Page 15
Responsabilit unique (SRP: Single Responsibility Principle) 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 cohsion, les responsabilits
tant regroupes
Page 16
Comment appliquer Pour une classe de taille importante, il est
souvent bnfique de lister toutes les mthodes, et de regrouper
celles dont le nom ou les actions semblent tre de la mme famille.
Si plusieurs groupes apparaissent dans une classe, c'est un bon
indicateur que la classe doit tre reprise.
Page 17
Comment appliquer Une autre mthode est de regarder les
dpendances externes de la classe. La mthode appelle-t-elle
directement la base de donnes ? Utilise-t'elle une API spcifique ?
Certains membres sont-ils appels uniquement par une fonction, ou
par un sous-ensemble de fonctions ? Si c'est le cas, ce sont
peut-tre des responsabilits annexes, dont il faut se
dbarrasser..
Page 18
Exemple Pour faire simple, on va prendre un mauvais exemple,
que l'on va refactoriser. Le pattern utilis nest pas mauvais en
soit, mais il ne respecte pas les rgles SOLID.
Page 19
Exemple Voir le mauvais exemple En termes de responsabilits,
cette classe a les responsabilits: de crer les objets de stocker
les donnes de l'objet et de grer la persistance des objets. Voir le
bon exemple.
Page 20
Exemple Suite cette factorisation, les responsabilits de nos
trois classes sont beaucoup plus videntes, la classe d'accs aux
donnes ne traite plus que des donnes, l'objet possde des mthodes
pour manipuler ses propres donnes, et la factory a la responsabilit
de faire travailler ensemble la classe d'accs aux donnes et
l'objet...
Page 21
Exemple Une notion garder l'esprit est qu'il ne faut pas aller
trop loin dans la sparation des responsabilits, au risque de tomber
dans un excs inverse.
Page 22
Ouvert/ferm (OCP: Open/closed Principle) Dfinition: "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 faons nouvelles et diffrentes
si les exigences de l'application sont modifies, ou pour remplir
les besoins d'une autre application. 2. Ils sont "Ferms la
modification". Le code source d'un tel module ne peut pas tre
modifi. Personne n'est autoris y apporter des modifications."
Page 23
Ouvert/ferm (OCP: Open/closed Principle) Le but de ce principe
est donc de tendre, non plus vers des objets immuables, mais vers
des objets auxquels les clients pourront ajouter de nouveaux
comportements sans en modifier la mcanique interne( laide de
lhritage).
Page 24
Ouvert/ferm (OCP: Open/closed Principle) Pour implmenter ce
principe il suffit de conserver un design simple, et lorsquon
arrive aux limites de ce design, d'en changer...
Page 25
Ouvert/ferm (OCP: Open/closed Principle) Comme rgles de bonne
conduite, on peut essayer d'une part de ne pas dpendre du type d'un
objet pour choisir un chemin de traitement. D'autre part, on peut
limiter l'hritage, en y prfrant la composition.
Page 26
Exemple Voir le bon et le mauvais exemple
Page 27
La substitution de Liskov Dfinition pour ceux qui veulent aller
lUniversit : Si pour chaque objet o1 de type S il existe un objet
o2 de type T tel que pour tout programme P dfini en termes de T, le
comportement de P est inchang quand on substitue o1 o2, alors S est
un sous-type de T.
Page 28
La substitution de Liskov Dfinition: Les sous-types doivent tre
remplaables par leur type de base. L, je vais en voir un ou deux
(ou plus) dire: Oui, mais partir du moment o ma classe S hrite de
ma classe T , je dois pouvoir caster S en T et l a va
marcher...
Page 29
La substitution de Liskov Le but de ce principe est exactement
de pouvoir utiliser une mthode sans que cette mthode ait connaitre
la hirarchie des classes utilises dans l'application, ce qui veut
dire: pas de cast pas de as pas de is
Page 30
La substitution de Liskov
Page 31
Ce principe apporte: Augmentation de l'encapsulation Diminution
du couplage. En effet, LSP permet de contrler le couplage entre les
descendants d'une classe et les clients de cette classe.
Page 32
La substitution de Liskov Comment l'appliquer: Pour dtecter le
non respect de ce principe, on va se poser la question de savoir si
on peut, sans dommage, remplacer la classe en cours par une
interface d'un niveau suprieur.
Page 33
Exemple Bien que ce soit compliquer comprendre le rsultat est
simple. Utiliser des noms significatifs pour pouvoir redfinir leur
comportement plutt que de crer plusieurs mthodes.
Page 34
Sparation des Interfaces (ISP: Interface Segregation Principle)
Dfinition: Les clients d'une entit logicielle ne doivent pas avoir
dpendre d'une interface qu'ils n'utilisent pas. Ce principe apporte
principalement une diminution du couplage entre les classes (les
classes ne dpendant plus les unes des autres). L'autre avantage
d'ISP est que les clients augmentent en robustesse.
Page 35
Sparation des Interfaces (ISP: Interface Segregation Principle)
Application: On va runir les groupes "fonctionnels" des mthodes de
la classe dans des Interfaces spares. L'ide tant de favoriser le
dcoupage de faon ce que des clients se conformant SRP n'aient pas
dpendre de plusieurs interfaces. Exemple: IList ICollection
IEnumerable Ilist Icollection IEnumerable
Page 36
Exemple Dans nos exemples de Work Items, on va devoir grer des
Work Items pour lesquels il existe une deadline. Nos Work Items
dpendant tous de IWorkItem, on va directement ajouter les
informations de gestion de deadline au niveau de IWorkItem et de
WorkItem.
Page 37
Exemple
Page 38
Jusqu'ici, tout va bien...Sauf que le marketing ne veut pas
entendre parler de deadline pour ses items. On peut donc, soit
renvoyer une information errone, pour continuer utiliser le
IWorkItem courant, soit se conformer au principe ISP, et sparer
notre interface en IWorkItem et IDeadLineDependent.
Page 39
Exemple
Page 40
L'intrt est que, si demain on a besoin d'une fonction
ExtendDeadline dans IDeadLineDependent, cela n'impactera pas les
WorkItems ne comportant pas de Deadline. Et si on ne le modifie
pas, on n'introduit pas de bugs.
Page 41
Inversion des dpendances (DIP: Dependency Inversion Principle)
Dfinition: Les modules de haut niveau ne doivent pas dpendre des
modules de bas niveau. Les deux doivent dpendre d'abstractions. Les
abstractions ne doivent pas dpendre des dtails. Les dtails doivent
dpendre des abstractions.
Page 42
Inversion des dpendances (DIP: Dependency Inversion Principle)
Dfinition: Si on change le mode de fonctionnement de la base
(passage de Oracle SQL Server), du rseau (changement de protocole),
de systme d'exploitation, les classes mtiers ne doivent pas tre
impactes. Inversement, le fait de changer les rgles de validation
au niveau de la partie mtier du framework ne doit pas demander une
modification de la base de donnes ( la limite, modifier une
fonction, mais ne pas changer les briques de base).
Page 43
Inversion des dpendances (DIP: Dependency Inversion Principle)
Ce principe est quivalent au principe d'Hollywood ("Ne nous appelez
pas, nous vous appellerons"),
Page 44
Inversion des dpendances (DIP: Dependency Inversion
Principle)
Page 45
Avantages: Une nette diminution du couplage Une meilleure
encapsulation, l'implmentation concrte pouvant ventuellement tre
choisie dynamiquement.
Page 46
Inversion des dpendances (DIP: Dependency Inversion Principle)
Comment l'appliquer: L'ide est que chaque point de contact entre
deux modules soit matrialis par une abstraction.
Page 47
Exemple
Page 48
Page 49
Conclusion Les principes SOLID dictes la philosophie adopter
lors de la conception ou la maintenance dun systme. Larchitecture
doit tre repens en cours de dveloppement. Ces points sont des
repres que vous dicterez les limites selon votre exprience.