transcript
- Page 1
- 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.