Télécharger la présentation
1
Les design patterns
2
Les design patterns Introduction Problèmes de conception
Schémas de conception un processus d’abstraction les schémas de Gamma schémas structurels schémas comportementaux schémas de création
3
Introduction Solutions simples et élégantes
De l’expérience à la connaisssance: Solutions simples et élégantes à des problèmes spécifiques de conception de logiciels OO
4
Introduction: The Gof Erich Gamma: ingénieur, consultant
C++, applications graphiques interactives(ET++), développement d’environnements OO Richard Helm: ingénieur chercheur Conception objet, réutilisation Ralph Johnson: enseignant chercheur OS objet(Choices), compilation, édition graphique, synthèse de musique John Vlissides: chercheur conception d’outilsOO, frameworks d’application, visualisation de programmes
5
Problèmes de conception
Concevoir du logiciel OO est difficile, Concevoir du logiciel OO réutilisable encore plus! déterminer les objets appropriés les décomposer en classes avec le niveau de détail adéquat définir les interfaces des classes, définir les hiérarchies d’héritage, établir les relations clés entre classes
6
Solutions aux problèmes de conception
Pour résoudre un problème: ne pas partir des mécanismes de base mais, réutiliser des solutions ayant fait leurs preuves Faciliter la réutilisation de solutions de conception, d’architectures efficaces
7
Solutions aux problèmes de conception
Les design patterns, expertise en COO, aident à: choisir les alternatives favorisant la réutilisabilité et éviter celles qui la compromettent améliorer la documentation, faciliter maintenance Mais ce ne sont pas des solutions clé en main !!
8
Schémas de conception: éléments constitutifs
Nom du modèle augmentation du vocabulaire de conception, donc du niveau d ’abstraction Applicabilité situation où le modèle s’applique Solution éléments, relations, responsabilités, coopérations Conséquences évaluation lors du choix d’un schéma
9
Un processus d’abstraction
Mise en évidence du concept qui varie Un niveau d’abstraction Un niveau de souplesse gagné par une utilisation pertinente de la composition
10
Schémas structurels Adaptateur Adapter (Wrapper) Composite
Décorateur Decorator Façade Fondé de pouvoir Proxy (Surrogate) Poids mouche Flyweight Poignée/Corps, Passerelle Bridge (Handle/Body)
11
Schémas comportementaux
Algorithmes et affectation des responsabilités entre objets Modèles de communication entre objets et classes Héritage pour répartir les comportements entre classes Composition d ’objets pour une tâche irréalisable par un seul d ’entre eux les objets communiquent par référence entre objets, à travers un certain nombre de niveaux d’indirections Encapsulation de comportement avec délégation de requête
12
Schémas comportementaux
Chaîne de responsabilité Chain of responsibility Commande Command Etat State Interpréteur Interpreter Itérateur Iterator Médiateur Mediator Observateur Observer Pense-bête Memento Squelette (d’algorithme) Template Method Stratégie Strategy Visiteur Visitor
13
Schémas de création Encapsulent la connaissance des classes concrètes que le système utilise Occultent la façon dont les instances de ces classes sont créées et assemblées => Grande liberté dans la détermination de ce qui doit être créé qui doit le créer comment le créer quand le créer
14
Schémas de création Constructeur virtuel Factory method
Ensemblier Builder Fabrique abstraite Abstract factory Prototype Singleton
15
Pour choisir un schéma de conception
Prendre en compte la manière dont les modèles de conception résolvent les problèmes de conception Etudier les interactions des modèles Etudier les modèles qui ont même rôle Analyser les motifs de refonte d’une conception Rechercher ce qui doit rester libre de varier
16
Utilisation d’un schéma de conception
Connaître très précisément le modèle Choisir, pour les constituants, des noms significatifs dans le contexte de l’application Définir les classes Définir les noms des opérations du modèle Implémenter les opérations Un schéma ne doit être appliqué que si la souplesse apportée est réellement nécessaire
17
Concevoir évolutif: défauts courants
Créer un objet en spécifiant explicitement sa classe Dépendance plates formes matérielles et logicielles Couplage fort Extension des fonctionnalités par sous-classe Impossibilité de modification convenable des classes
18
Patterns de comportement
Eduard Turcan IISLAB, IDA
19
Introduction Les patterns de comportement:
concernent les algorithmes et les assignements des responsabilités entre objets. Décrivent des schémas de communication entre objets. Les patterns de classe/d’objet Les patterns de classe utilisent l’héritage pour distribuer le comportement aux sous-classes. Les patterns d’objet utilisent la composition
20
Iterator But – Fournir un moyen d’accéder séquentiellement aux éléments d’un objet agrégé sans exposer sa structure interne. Structure and Participants Iterator ConcreteIterator Aggregate ConcreteAggregate CreateIterator() First() Next() IsDone() CurrentItem() return new ConcreteIterator(this); Client Utilisation – Quand vous voulez: Accéder à un objet agrégé sans exposer son organisation interne Pour gérer simultanément plusieurs parcours dans des agrégats. Pour offrir une interface uniforme pour les parcours au travers d’agrégats hétérogènes (i.e. pour permettre l’itération polymorphe). Iterator defines an interface for accessing and traversing elements. implements the Iterator interface. keeps track of current position in the traversal of the aggregate. Aggregate defines an interface for creating an Iterator object. ConcreteAggregate implements the Iterator creation interface to return an instance of the proper ConcreteIterator.
21
Observer But – Définit une interdépendance de type un à plusieurs, de façon que, quand un objet change d’état, tous ceux qui en dépendent en soient notifiés et automatiquement mis à jour. Structure and Participants Subject Observer ConcreteSubject ConcreteObserver Update() observers observerState observerState = subject->GetState() for all o in observers { o ->Update() } Return subjectState GetState() SetState() subjectState Attach(Observer) Detach(Observer) Notify() subject Utilisation : Quand un concept a 2 représentations, l’une dépendant de l’autre. Encapsuler ces 2 représentations dans des objets permet de les réutiliser indépendamment. Quand la modification d’un objet nécessite de modifier les autres et que l’on ne sait pas combien sont ces autres Quand un objet doit faire une notification à d’autres objets sans connaître la nature de ces objets (couplage faible). Subject knows its observers. Any number of Observer objects may observer a subject. Observer defines an updating interface for objects that should be notified of changes in a subject. ConcreteSubject stores state of interest to ConcreteObserver objects. sends an notification to its observers when its state changes. ConcreteObserver maintains a reference to a ConcreteSubject object. stores state that should stay consistent with the object's. implements the Observer updating interface to keep its state consistent with the subject's.
22
State But – Permet à un objet de modifier son comportement, quand son état interne change. Tout se passera comme si l’objet changeait de classe. Structure and Participants Context State ConcreteState subclasses ConcreteState A Handle() ConcreteState B state ->Handle() Request() state Utilisation - Quand: Le comportement d’un objet dépend de son état, et ce changement de comportement doit intervenir dynamiquement, en fonction de son état. Les opérations comportent de grands blocs de déclarations conditionnelles fonctions de l’état de l’objet. Context defines the interface of interest to clients. maintains an instance of a ConcreteState subclass that defines the current state. State defines an interface for encapsulating the behavior associated with a particular state of the Context. ConcreteState subclasses each subclass implements a behavior associated with a state of the Context.
23
Strategy But – Définit une famille d’algorithmes, les encapsule et les rend interchangeables. Il rend l’algorithme très indépendant des clients qui l’utilisent. Structure and Participants Strategy ConcreteStrategy Context ConcreteStrategy A AlgorithmInterface() ConcreteStrategy B ContextInterface() strategy ConcreteStrategy C Utilisation - Quand: Plusieurs classes apparentées ne diffèrent que par leur comportement. Les stratégies donnent un moyen d’appareiller une classe avec un comportement. On a besoin de diverses variantes d’un algorithme (compromis temps/mémoire). Une algorithme utilise des données que les clients n’ont pas à connaître. Les stratégies dispense d’avoir à révéler leurs données spécifiques. Une classe définit de nombreux comportements, qui figurent dans ses opérations sous la forme de déclaration conditionnelles multiples. Strategy declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy. ConcreteStrategy implements the algorithm using the Strategy interface. Context is configured with a ConcreteStrategy object. maintains a reference to Strategy object. may define an interface that lets Strategy access its data.
24
Template Method But – Définit dans une opération, le squelette d’un algorithme, en déléguant certaines étapes à des sous-classes. Le patron de méthode permet de redéfinir par des sous-classes, des parties d’un algorithme, sans avoir à modifier sa structure. Structure and Participants AbstractClass ConcreteClass ... PrimitiveOperation1() ... PrimitiveOperation2() ... PrimitiveOperation1() PrimitiveOperation2() TemplateMethod() PrimitiveOperation1() PrimitiveOperation2() Utilisation: Pour implémenter une fois pour toutes les parties invariantes d’un algorithme, et laisser aux sous-classes le soin d’implémenter les parties dont le comportement est variable. Quand, pour éviter la duplication de code, il faut isoler le facteur commun des comportements des sous-classes, et l’implanter dans une classe commune. Pour contrôler les extensions des sous-classes. AbstractClass defines abstract primitive operations that concrete suubclasses define to implement steps of an algorithm. implements a template method defining the skeleton of an algorithm. ConcreteClass implements the primitive operations to carry out subclass-specific steps of the algorithm
25
Visitor But – Permet de définir une nouvelle opération, sans qu’il soit nécessaire de modifier la classe des éléments sur lesquels elle agit. Structure and Participants Visitor ConcreteVisitor Element ConcreteElement ObjectStructure ConcreteElement A Accept(Visitor v) OperationA() Concrete Element B Accept(Visitor v) OperationB() Accept(Visitor) v->VisitConcreteElementA(this) v->VisitConcreteElementB(this) ConcreteVisitor1 VisitConcreteElementA(ConcreteElementA) VisitConcreteElementB(ConcreteElementB) Utilisation - Quand: Une structure d’objets contient beaucoup de classes différentes d’interfaces distinctes, et l’on veut réaliser des opérations sur ces objets. Plusieurs opérations distinctes et sans relation entre elles, doivent être effectuées sur les objets d’une structure et ceci en évitant de polluer les classes avec ces traitements. La structure d’objet change rarement, mais l’on doit souvent définir de nouvelles opérations. Visitor declares a Visit operation for each class of ConcreteElement in the object structure. The operation's name and signature identifies the class that sends the Visit request to the visitor. That lets the visitor determine the concrete class of the element being visited. Then the visitor can access the element directly through its particular interface. ConcreteVisitor implements each operation declared by Visitor. Each operation implements a fragment of the algorithm defined for the corresponding class of object in the structure. ConcreteVisitor provides the context for the algorithm and stores its local state. This state often accumulates results during the traversal of the structure. Element defines an Accept operation that takes a visitor as an argumenet. ConcreteElement implements an Accept operation that takes a visitor as an argument.
26
Encapsulation du variable Objet passé en argument
Conclusion Encapsulation du variable Iterator, State, Strategy Objet passé en argument Visitor Communication distribuée Observer Découpler les emetteurs et les recepteurs
27
Le pattern fabrique abstraite
28
Look-and-Feel Garantir la portabilité d’un système sur une variété de plates-formes matérielles et logicielles Standard de «look-and-feel» uniformité de présentation des applications ni même aspect ni même comportement sur différents standards => une application fonctionnant sur différentes plates formes doit se conformer aux guides de style de leurs interfaces utilisateurs
29
Objectifs Etre en conformité avec différents standards
Faciliter l’ajout de nouveaux standards Possibilité de modifier le décor à l’exécution
30
Widget Modélisation de classes widgets pour l’implémentation de différents standards de « look-and-feel » classes abstraites pour chaque catégorie de widget classes concrètes implémentant les précédentes (par standard)
31
Widget Widget Ascenseur Défile Bouton Presse Menu Déroule
AscenseurMotif Défile AscenseurPM AscenseurMac BoutonMotif Presse BoutonPM BoutonMac MenuMotif Déroule MenuMac MenuPM
32
Création d’objets Création d’une instance de AscenseurMotif: Ascenseur ascenseur = new AscenseurMotif Risque de cohabitation avec Bouton bouton = new BoutonMac Forte dépendance de l’application par rapport à l’interface =>Augmenter le niveau d’abstraction de l’interface entre utilisateur et widgets selon le critère «type de standard»
33
Création d’objets A un instant donné, ne disposer que de widgets correspondant à un standard unique… pas d’appel direct aux différents constructeurs connaissance du standard en vigueur possibilité de changement complet de décor
34
Fabrique/Produit FabriqueGui CreeAscenseur CreeBouton CreeMenu
FabriqueMotif CreeAscenseur CreeBouton CreeMenu FabriqueMac CreeAscenseur CreeBouton CreeMenu FabriqueMP CreeAscenseur CreeBouton CreeMenu
35
Fabrique/Produit Widget FabriqueGui CreeAscenseur CreeBouton CreeMenu
Défile Bouton Presse Menu Déroule FabriqueMac CreeAscenseur CreeBouton CreeMenu AscenseurMac Défile BoutonMac Presse MenuMac Déroule FabriqueMotif CreeAscenseur CreeBouton CreeMenu FabriqueMP CreeAscenseur CreeBouton CreeMenu AscenseurMotif Défile AscenseurPM Défile BoutonMotif Presse MenuMotif Déroule BoutonPM Presse MenuPM Déroule AscenseurMac BoutonMac MenuMac
36
Fabrique/Produit Surtout pas: Ascenseur MonAscenseur =
Schéma fabrique abstraite: exemple Fabrique/Produit Surtout pas: Ascenseur MonAscenseur = new AscenseurMac() Mais plutôt: Ascenseur MonAscenseur= FabriqueGUI.CreeAscenseur() avec FabriqueGUI instance de FabriqueMac
37
Fabrique/Produit Fabriques créent des objets produits
Produits apparentés issus d’une même fabrique Origine de l’instance de FabriqueGUI: initialisée avant utilisation et après choix du décor initialisation simple choix en fonction de l’environnement
38
Look-and-Feel et Fabrique Abstraite
Création de familles d’objets apparentés sans instanciation directe des classes de ces objets par instanciation d’une fabrique concrète chargée de l’instanciation des produits spécifiques Recommandé quand nombre et type de produits stables différences uniquement entre familles de produits
39
Structure Client FabriqueAbstraite CreeProduitA CreeProduitB
ProduitAbstraitA ProduitA2 ProduitA1 FabriqueConcrete1 CreeProduitA CreeProduitB FabriqueConcrete2 ProduitAbstraitB ProduitB2 ProduitB1
40
Conséquences Isole les classes concrètes
Facilite la substitution de familles de produits Favorise le maintien de la cohérence entre les objets Créer de nouveaux types de produits est difficile
41
Le pattern Singleton Démo
42
Questions ? Joyeux noël, bonne année, bla bla bla… et boivez pas trop pendant les fêtes !!
Présentations similaires
© 2024 SlidePlayer.fr Inc.
All rights reserved.