révision et principes solid architecture dapplication hugo st-louis

Rvision et principes SOLID Architecture dapplication Hugo St-Louis

PollEv.com

Dont forget: You can copy-paste this slide into other presentations, and move or resize the poll. Poll: Pourquoi utiliser un fichier de configur...

Dont forget: You can copy-paste this slide into other presentations, and move or resize the poll. Poll: Pour une application multilingue, qu'est...

Dont forget: You can copy-paste this slide into other presentations, and move or resize the poll. Poll: L'objectif de ce cours est.....

Introduction aux principes SOLID Architecture dapplication Hugo St-Louis

Plan Introduction Principes SOLID Conclusion

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

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

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

Responsabilit unique (SRP: Single Responsibility Principle)

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.

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

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.

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..

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.

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.

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...

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.

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."

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).

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...

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.

Exemple Voir le bon et le mauvais exemple

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.

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...

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

La substitution de Liskov

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.

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.

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.

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.

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

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.

Exemple

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.

Exemple

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.

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.

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).

Inversion des dpendances (DIP: Dependency Inversion Principle) Ce principe est quivalent au principe d'Hollywood ("Ne nous appelez pas, nous vous appellerons"),

Inversion des dpendances (DIP: Dependency Inversion Principle)

Avantages: Une nette diminution du couplage Une meilleure encapsulation, l'implmentation concrte pouvant ventuellement tre choisie dynamiquement.

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.

Exemple

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.

révision et principes solid architecture dapplication hugo st-louis

Documents

martin page

practices page

si une classe

cette classe

lobjet et

ce sont peuttre

openclosed principle

et lorsquon