La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

R ÉVISION Les principes SOLID. Q UESTION Quest-ce que le S de Solid?

Présentations similaires


Présentation au sujet: "R ÉVISION Les principes SOLID. Q UESTION Quest-ce que le S de Solid?"— Transcription de la présentation:

1 R ÉVISION Les principes SOLID

2 Q UESTION Quest-ce que le S de Solid?

3 R ESPONSABILITÉ UNIQUE (SRP: S INGLE R ESPONSIBILITY P RINCIPLE ) Le principe de responsabilité unique, réduit à sa plus simple expression, est qu'une classe donnée ne doit avoir qu'une seule responsabilité, et, par conséquent, qu'elle ne doit avoir qu'une seule raison de changer.

4 Q UESTION Quest-ce que le O de Solid?

5 O UVERT / FERMÉ (OCP: O PEN / CLOSED P RINCIPLE ) Définition: "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 façons nouvelles et différentes si les exigences de l'application sont modifiées, ou pour remplir les besoins d'une autre application. 2 - Ils sont "Fermés à la modification". Le code source d'un tel module ne peut pas être modifié. Personne n'est autorisé à y apporter des modifications.« Bref, il ne faut pas briser la logique de lhéritage.

6 Q UESTION Quest-ce que le L de Solid?

7 L A SUBSTITUTION DE L ISKOV Définition: Les sous-types doivent être remplaçables 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 hérite de ma classe T », je dois pouvoir caster S en T et là ça va marcher...

8 Q UESTION Quest-ce que le I de Solid?

9 S ÉPARATION DES I NTERFACES (ISP: I NTERFACE S EGREGATION P RINCIPLE ) Définition: Les clients d'une entité logicielle ne doivent pas avoir à dépendre d'une interface qu'ils n'utilisent pas. Ce principe apporte principalement une diminution du couplage entre les classes (les classes ne dépendant plus les unes des autres). L'autre avantage d'ISP est que les clients augmentent en robustesse.

10 Q UESTION Quest-ce que le I de Solid?

11 I NVERSION DES DÉPENDANCES (DIP: D EPENDENCY I NVERSION P RINCIPLE ) Définition: Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre d'abstractions. Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions.

12 L ECTURE OBLIGATOIRE Pourquoi développer en utilisant les couches ? Quest-ce l es objets métier ? À quoi sert la couche daccès aux données Quest-ce que l a couche métier ? Quel patron de conception(design pattern) avez-vous vue dans le document?

13 L ES DESIGNS PATTERN Architecture dapplication – Hugo St-Louis Hiver 2011

14 O BJECTIFS DE LA PRÉSENTATION Comprendre ce qu'est un pattern En connaître les principaux représentants Exemples d'utilisation Des ressources pour aller plus loin Apporter des idées conceptuelles

15 D ÉFINITION D UN DESIGN PATTERN Modèles de conception parfois aussi « Motifs de conception » ou « Patrons de conception ». Solutions à des problèmes classiques. (Règle de 3 utilisations) Indépendants du langage.

16 I LS SONT PARTOUT... Composition musicale (cadence, appogiatures, tonalité, rubato,...) Communication (intonations dans le discours, métaphores et exemples,...) Graphisme, ergonomie (positionnements, codes couleurs,...)... Tout ce qui représente une façon de procéder pour arriver à un résultat

17 A PPARITION DES PATTERNS C. Alexander « A Pattern Language: Towns, Buildings, Construction » [1977] « Chaque modèle décrit un problème qui se manifeste constamment dans notre environnement, et donc décrit le cœur de la solution à ce problème, de telle façon que l'on puisse la réutiliser des millions de fois et ce jamais de la même manière » [AIS+ 77]

18 L' OUVRAGE DE RÉFÉRENCE GoF « Gang of Four » Design patterns. Elements of reusable ObjectOriented Software [1994] Erich Gamma, Richard Helm, Ralph Johnson John Vlissides

19 P OURQUOI LES ÉTUDIER ? Catalogue de solutions. Bénéficier du savoir faire d'experts dans des contextes éprouvés. (fiables, robustes & connus) Facilite la conception.

20 P OURQUOI LES UTILISER ? Ne pas réinventer la roue. Facilite la communication entre développeurs. Pour résoudre un problème

21 D IVISION DES PATTERNS Les patterns sont divisés en 3 groupes: Création Structure Comportement

22 L ES 5 PATTERNS DE CRÉATION Pattern de Création Factory method, AbstractFactory, Builder, Prototype, Singleton Abstraction du processus de création. Encapsulation de la logique de création. On ne sait pas à l'avance ce qui sera créée ou comment cela sera créé.

23 L ES 7 PATTERNS DE STRUCTURE Les pattern de Structure Adapter, Bridge, Composite, Decorator, Interface, Flyweight, Proxy Comment sont assemblés les objets. Découpler l'interface de l'implémentation.

24 L ES 11 PATTERNS COMPORTEMENTAUX Les pattern de Comportement Interpretor, Template method, Chain of responsability, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Visitor Mode de communication entre les objets

25 Q UELQUES EXEMPLES POUR COMMENCER Singleton (Création) Factory method(Création) Adapter (Structure) Decorator (Structure) Visitor (Structure) Observer (Comportement) Iterator (Comportement) States (Comportement)

26 [C RÉATION ] S INGLETON Problématique : S'assurer qu'il existe une seule instance d'un objet donné pour toute l'application. Solution : Une méthode statique pour contrôler l'instanciation. Rendre ce processus d'instanciation l'unique solution possible pour la classe en question.

27 [C RÉATION ] S INGLETON, DIAGRAMME

28 [C RÉATION ] S INGLETON, PIÈGES & DIFFÉRENCES N'est pas une classe statique Une instance à manipuler. Conserve un contexte Peut être passé en paramètre à une méthode N'est pas une variable globale Eviter la singletonite

29 [C RÉATION ] S INGLETON, EXEMPLE

30 [C RÉATION ] S INGLETON, E XERCICE Faites un programme qui permet de répartir la charge sur un serveur(LoadBalancing). Ce programme retourne une adresse de connexion au hasard à partir dune liste. La classe qui contient(distribue) les adresses doit être un singleton car ladministrateur peut ajouter/supprimer des adresses en tout temps.

31 [C RÉATION ] F ACTORY METHOD Problématique : Obtenir facilement un objet prêt à l'emploi et qui correspond à nos besoins. Solution : Une classe / Une méthode qui encapsule la logique de création des objets en question. Ce patron permet d'instancier des objets dont le type est dérivé d'un type abstrait. La classe exacte de l'objet n'est donc pas connue par l'appelant.

32 [C RÉATION ] F ACTORY METHOD, DIAGRAMME

33 [C RÉATION ] F ACTORY M ETHOD, EXEMPLE

34 [C OMPORTEMENT ] I TERATOR Problématique : Parcourir des collections d'objets diverses, éventuellement de différentes façons, sans risque pour le contenu. Solution : Utiliser un objet qui dispose de la connaissance nécessaire à la navigation dans la collection avec une interface unique.

35 [C OMPORTEMENT ] I TERATOR, DIAGRAMME

36 [C OMPORTEMENT ] I TERATOR

37 [C OMPORTEMENT ] STATE Problématique : Permettre un comportement différence en fonction dun contexte(valeur) Solution : Gérer un état qui permet de rediriger le comportement vers la bonne classe.

38 [C OMPORTEMENT ] STATE, DIAGRAMME

39 [C OMPORTEMENT ] STATE

40 E XERCICE : [C OMPORTEMENT ] STATE Vous devez concevoir un programme qui utilise le pattern « state » qui permet à un compte bancaire davoir différent état(statut) soit les suivants: RedState Limite du type de compte[-500 $, 0$[; Intérêt annuel : 0% Frais de service pour chaque retrait : 15$ SilverState Limite du type de compte[0$, 1000$[; Intérêt annuel : 0% Frais de service pour chaque retrait : 1$ GoldState Limite du type de compte[1000$, $. Intérêt annuel : 5% Frais de service pour chaque retrait: 0$

41 [C OMPORTEMENT ] O BSERVER Problématique : Permettre à un objet de réagir aux comportement d'un autre sans pour autant les lier « en dur ». Solution : Définir un objet comme « observable » et donc capable de notifier des changements à des observateurs, quels qu'ils soient.

42 [C OMPORTEMENT ] O BSERVER

43 [C OMPORTEMENT ] O BSERVER, EXEMPLE

44 [C OMPORTEMENT ] O BSERVER, E XERCICE Faite un programme qui permet de notifier les investisseurs boursiers à chaque fois quune côte de la bourse change.

45 [S TRUCTURE ] A DAPTER Problématique : Ajuster l'interface d'un objet à celle attendue par le code client. Solution : L'adaptateur conserve une instance de la classe adaptée et convertit les appels d'une interface existante vers l'interface implémentée.

46 [S TRUCTURE ] A DAPTER, DIAGRAMME

47 A DAPTER, EXEMPLE

48 Q UIZZ Quel pattern pourrait on mettre a contribution pour avoir une seule instance de logBase accessible dans notre application ? Quel pattern pourrait on mettre a contribution pour obtenir rapidement un « LogBase » correctement configuré avec ses observers ?

49 [S TRUCTURE ] D ECORATOR Problématique : Rajouter des fonctionnalités à des composants existants sans utiliser l'héritage. Solution : Encapsuler l'objet existant et y ajouter des comportements nouveaux.

50 [S TRUCTURE ] D ECORATOR, DIAGRAMME

51 [S TRUCTURE ] D ECORATOR, EXEMPLE

52 [S TRUCTURE ] D ECORATOR VS H ÉRITAGE

53 [S TRUCTURAUX ] V ISITOR Problématique : On souhaite réaliser des opérations sur les éléments d'un objet sans pour autant connaître à l'avance le résultat à obtenir. Solution : On utilise un objet tiers (visiteur) qui sera capable d'obtenir le résultat souhaité à partir des données.

54 [S TRUCTURAUX ] V ISITOR

55 [[S TRUCTURAUX ] V ISITOR


Télécharger ppt "R ÉVISION Les principes SOLID. Q UESTION Quest-ce que le S de Solid?"

Présentations similaires


Annonces Google