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

Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 6: Using Design Patterns.

Présentations similaires


Présentation au sujet: "Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 6: Using Design Patterns."— Transcription de la présentation:

1 Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 6: Using Design Patterns

2 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns2 6.1 Introduction aux Patrons de conception Les aspects récurrents dun design sont appelés patrons de conception. Un patron est lesquisse dune solution réutilisable à un problème général rencontré dans un contexte particulier Plusieurs de ces patrons ont été documentés et mis à la disposition des développeurs afin quil puissent en faire usage. Un bon patron de conception devrait Être aussi général que possible Contenir une solution qui a été démontrée efficace pour résoudre un problème précis dans un contexte identifié. Létude des patrons de conception est une façon efficace dapprendre à partir de lexpérience des autres

3 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns3 Description dun patron de conception Contexte: La situation générale ou le patron sapplique Problème: Une ou deux courtes phrases résumant la difficulté principale. Forces: Les principaux points à considérer dans la résolution du problème Solution: La manière recommandée de résoudre le problème dans un contexte donné Anti-patrons: (Optionnel) Solutions de moindre qualité ou inadéquate dans le contexte donné Patrons apparentés: (Optionnel) Patrons similaire au patron proposé. Références: Le concepteur du patron ou celui qui la inspiré.

4 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns4 6.2 Le patron Abstraction-Occurrence Contexte: Souvent, dans le modèle du domaine, il existe un ensemble dobjets liés entre eux (occurrences). Les membres dun tel ensemble partagent une information commune -Bien quils diffèrent aussi. Problème: Quelle est la meilleure façon de représenter un tel ensemble doccurrences dans un diagramme de classes? Forces: Vous souhaitez représenter les propriétés de chaque ensemble doccurrences sans avoir à dupliquer linformation commune

5 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns5 Abstraction-Occurrence Solution:

6 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns6 Abstraction-Occurrence Anti-patrons:

7 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns7 Abstraction-Occurrence Variante en carré

8 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns8 6.3 Le patron de Hiérarchie généralisée Contexte: Les objets dune hiérarchie peuvent avoir un ou plusieurs objets au-dessus deux (leurs supérieurs), -Et un ou plusieurs objets sous eux (leurs subordonnés). Certains objets ne peuvent avoir de subordonnés Problème: Comment représenter une telle hiérarchie dobjets dans laquelle certains objets ne peuvent avoir de subordonnés? Forces: Vous recherchez une solution flexible afin de représenter une hiérarchie générale Les objets partagent plusieurs propriétés et comportements communs

9 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns9 Hiérarchie généralisée Solution:

10 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns10 Solution: Hiérarchie généralisée

11 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns11 Hiérarchie généralisée Anti-patron:

12 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns Le patron Acteur-Rôle Contexte: Un rôle correspond à un ensemble de propriétés particulières associées à un objet dans un contexte particulier. Un objet peut jouer plusieurs rôles dans différents contextes. Problème: Comment modélisé une situation ou un objet peut jouer plusieurs rôles (conjointement ou consécutivement)?

13 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns13 Acteur-Rôle Forces: Il est souhaitable de renforcer lencapsulation en intégrant linformation associée à chaque rôle dans des classes distinctes. Il faut éviter lhéritage multiple. Un objet ne peut changer de classe dappartenance Solution:

14 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns14 Acteur-Rôle Exemple 1:

15 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns15 Acteur-Rôle Exemple 2:

16 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns16 Acteur-Rôle Anti-patrons: Fusionner tous les comportements et propriétés dans une seule classes. Créer des rôles étant sous-classes de la classe acteur.

17 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns Le patron Singleton Contexte: Il est fréquent de retrouver des classes pour lesquelles il ne doit exister quune seule instance (singleton) Problème: Comment assurer quil ne sera jamais possible de créer plus dune instance de cette classe? Forces: Lexistence dun constructeur publique ne peut garantir que plus dune instance sera créée. Linstance du singleton doit être accessible de toutes les classes qui en ont besoin

18 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns18 Singleton Solution:

19 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns The patron Observateur Contexte: Quand une association est créee entre deux classes, celles-ci deviennent inséparables. Si vous souhaitez réutilisée lune de ces classes, la seconde doit aussi être réutilisée. Problème: Comment réduire linterconnexion entre classes, en particulier si elle appartiennent à des modules ou des sous-systèmes différents? Forces: Vous souhaitez maximiser la flexibilité du système

20 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns20 Observateur Solution:

21 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns21 Observateur Anti-patrons: Connecter un observateur directement à un observé de façon telle que chacun contient une référence à lautre. Faire des observateurs une sous-classe des observés.

22 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns Le patron Délégation Contexte: Vous devez concevoir une méthode dans une classe Vous réalisez quune autre classe possède une méthode qui fournit le service requis Lhéritage nest pas approprié Problème: Comment réutiliser une méthode existant dans une autre classe? Forces: Vous souhaitez minimiser le temps de développement par la réutilisation

23 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns23 Délégation Solution:

24 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns24 Délégation Exemple:

25 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns25 Délégation Anti-patrons Utiliser la généralisation et ainsi hériter de la méthode ainsi que de toutes les autres Au lieu davoir une seule méthode dans le délégant appelant la méthode du délégué, avoir plusieurs méthodes appelant la méthode du délégué Accéder à des classes lointaine return specificFlight.regularFlight.flightNumber(); return getRegularFlight().flightNumber();

26 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns Le patron Adaptateur Contexte: Une hiérarchie existe et vous souhaitez y incorporer une classe existante. Cette classe fait aussi partie dune autre hiérarchie. Problème: Comment bénéficier du polymorphisme en réutilisant une classe dont les méthodes ont les même fonctions mais pas la même signature que celles de la hiérarchie existante? Forces: Vous navez pas accès à lhéritage multiple ou vous ne voulez pas y avoir recours.

27 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns27 Adaptateur Solution:

28 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns28 Adaptateur Exemple:

29 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns La patron Façade Contexte: Souvent, une application contient plusieurs paquetages complexes. Un programmeur travaillant avec une librarie de classes doit manipuler de nombreuses classes Problème: Comment simplifier la tâche des programmeurs lorsquils interagissent avec une librairie complexe? Forces: Il est difficile pour un programmeur de comprendre et dutiliser un sous-système entier Si plusieurs classes dune application appellent les méthodes de cette librairie, alors toute modification à celle-ci nécessitera une revue complète de tout le système.

30 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns30 Façade Solution:

31 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns Le patron Immuable Context: Un objet immuable est un objet dont létat ne change jamais Problème: Comment créer un objet dont les instances sont immuables? Forces: Il ne doit exister aucun moyen daltérer létat dun objet immuable Solution: Sassurer que le constructeur dun objet immuable est le seul endroit ou les valeurs dun objet sont fixées. Aucune méthode ne doit modifier létat de lobjet. Si une méthode devrait avoir pour effet un changement détat, alors une nouvelle instance est retournée.

32 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns Le patron en mode lecture seule Contexte: Il faut parfois avoir certaines classes privilégiées ayant la capacité de modifier un objet immuable Problème: Comment permettre une situation oèu une classe est en mode lecture seule pour certaines classes tout en étant modifiable par dautres? Forces: Restreindre laccès par les mot-clés public, protected et private nest pas adéquat. Rendre public une méthode, la rend accessible à tous

33 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns33 Linterface en mode lecture seule Solution:

34 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns34 Linterface en mode lecture seule Example:

35 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns35 Linterface en mode lecture seule Anti-patrons: Faire de la classe en mode lecture seule, une sous-classe de la classe immuable Redéfinir toutes les méthodes modifiantes de façon à ce quelle lancent une exception

36 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns Le patron Mandataire Contexte: Fréquemment, il est coûteux et complexe de créer une instance de certaines classes (ce sont des classes lourdes). Leur création exige du temps Problème: Comment réduire la fréquence de création de classes lourdes? Forces: En fonction des tâches à accomplir, tous les objets dun système doivent demeurer disponibles lors de lexécution du système. Il est aussi important davoir des objets dont les valeurs persistent dune exécution à lautre

37 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns37 Mandataire Solution:

38 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns38 Mandataire Exemples:

39 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns Le patron Fabrique Contexte: Un cadriciel réutilisable a besoin de créer des objets; toutefois, les objets à créer dépendent de lapplication. Problème: Comment permettre à un programmeur dajouter des clases spécifiques à son application dans un système construit à partir dun cadriciel? Forces: Il faut que le cadriciel puisse créer des classes de lapplication, bien quil ne connait pas ces classes. Solution: Le cadriciel délègue la création des classes à une classe spécialisée appelée la Fabrique. La fabrique est une interface générique définie dans le cadriciel. Cette interface contient une méthode dont le but est de créer des instance de sous-classes dune classe générique.

40 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns40 La Fabrique Solution

41 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns41 La Fabrique Exemple

42 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns Exemple: intégrer des patrons de conception à OCSF

43 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns43 La couche Observable de OCSF

44 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns44 Utilisation de la couche observable de OCSF 1. Créer une classe réalisant linterface Observer. 2. Inscrire cette classe auprès de Observable: public MessageHandler(Observable client) { client.addObserver(this);... } 3. Définir une méthode update dans cette classe: public void update(Observable obs, Object message) { if (message instanceOf SomeClass) { // process the message }

45 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns Difficultés et Risques lors de la création de diagrammes de classes Les patrons ne sont pas une panacé: Il ne faut pas aveuglément appliquer les patrons dès que loccasion semble se présenter. Ceci peut mener à des décisions inappropriées. Résolution: Toujours bien comprendre les forces de chacun des patrons à appliquer. Sassurer de bien justifier chacune des décisions prises.

46 © Lethbridge/Laganière 2005 Chapter 6: Using design patterns46 Difficultés et Risques lors de la création de diagrammes de classes Développer un bon patron est difficile La création dun bon patron est une chose difficile et exigeante. Un patron mal conçu présente dintérêt Résolution: Ne pas concevoir des patrons jusquà ce que vous soyez suffisamment expérimenté. Suivre des formations sur lutilisation des patrons de conception. Faites réviser les patrons que vous concevez par vos pairs.


Télécharger ppt "Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 6: Using Design Patterns."

Présentations similaires


Annonces Google