Rvision du modle MVC et du perceptron 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: Qu'est-ce qu'un
perceptron?
Page 5
Dont forget: You can copy-paste this slide into other
presentations, and move or resize the poll. Poll: Qu'est-ce qu'un
critre de convergence?
Page 6
Dont forget: You can copy-paste this slide into other
presentations, and move or resize the poll. Poll: quoi sert le
vecteur de poids synaptiq...
Page 7
Dont forget: You can copy-paste this slide into other
presentations, and move or resize the poll. Poll: Comment
interroger un perceptron?
Page 8
Dont forget: You can copy-paste this slide into other
presentations, and move or resize the poll. Poll: Pourquoi utiliser
le modle MVC?
Page 9
Dont forget: You can copy-paste this slide into other
presentations, and move or resize the poll. Poll: Qu'est-ce que la
Business Logic(BL)?
Page 10
Dont forget: You can copy-paste this slide into other
presentations, and move or resize the poll. Poll: Dans le modle
MVC, qu'est-ce que la cou...
Page 11
Dont forget: You can copy-paste this slide into other
presentations, and move or resize the poll. Poll: Dans le modle
MVC, qu'est-ce que la cou...
Page 12
Dont forget: You can copy-paste this slide into other
presentations, and move or resize the poll. Poll: Dans le modle
MVC, qu'est-ce que la cou...
Page 13
Lecture Obligatoire Vous devez lire le fichier architecture.pdf
sur le site Internet du cours. Ce document explique larchitecture
en couche selon une approche intressante. IMPORTANT POUR
LEXAMEN!!!
Page 14
Introduction aux principes SOLID Architecture dapplication Hugo
St-Louis
Page 15
Introduction aux principes SOLID Architecture dapplication Hugo
St-Louis
Page 16
Plan Introduction Principes SOLID Conclusion
Page 17
Introduction Mtrique dun bon programme objet Cohsion: Une
classe => une tche Couplage: Liens entre les objets pour former
un tout. Encapsulation: Rendre invisible limplmentation
Page 18
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 19
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 20
Responsabilit unique (SRP: Single Responsibility
Principle)
Page 21
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 22
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 23
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 24
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 25
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 26
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 27
Exemple Suite a 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 28
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 29
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 30
Ouvert/ferm (OCP: Open/closed Principle) Pour quelles raisons
voudrait-on pouvoir mettre notre programme en conformit avec ce
principe ? Plus de flexibilit par rapport aux volutions Diminution
du couplage
Page 31
Ouvert/ferm (OCP: Open/closed Principle) Deux possibilits nous
sont donnes, la premire tant de chercher identifier une fonction ou
une mthode dont le comportement est susceptible d'tre fortement
impact par une modification ultrieure. => Difficile La seconde
mthode, plus agile, est de conserver un design simple, et lorsquon
arrive aux limites de ce design, d'en changer...
Page 32
Ouvert/ferm (OCP: Open/closed Principle) On va donc, le plus
souvent, commencer par le code le plus simple pouvant fonctionner,
et, lorsque l'on rencontre une exception nous obligeant modifier la
classe pour l'tendre, s'assurer qu'une modification ultrieure de
mme type ne nous forcera pas modifier de nouveau notre design.
Page 33
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. Est-ce que vous
reconnaissez un design pattern?
Page 34
Exemple Aprs une itration, on va avoir une nouvelle demande de
notre client (interne, mais client quand mme), savoir qu'il veut
pouvoir grer plusieurs types de work items. Voir le bon et le
mauvais exemple
Page 35
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 36
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 37
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 38
La substitution de Liskov
Page 39
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 40
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 41
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 42
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 43
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 44
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 45
Exemple
Page 46
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 47
Exemple
Page 48
L'intrt est que, si demain on a besoin d'une fonction
ExtendDeadline dans IDeadLinedItem, 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 49
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 50
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 51
Inversion des dpendances (DIP: Dependency Inversion Principle)
Ce principe est quivalent au principe d'Hollywood ("Ne nous appelez
pas, nous vous appellerons"),
Page 52
Inversion des dpendances (DIP: Dependency Inversion
Principle)
Page 53
Avantages: Une nette diminution du couplage Une meilleure
encapsulation, l'implmentation concrte pouvant ventuellement tre
choisie dynamiquement.
Page 54
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. Est-ce que a vous
fait penser quelque chose????
Page 55
Exemple
Page 56
Page 57
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.