SlideShare une entreprise Scribd logo
1  sur  60
Télécharger pour lire hors ligne
Design Patterns

Présenté par Eric TOGUEM
Introduction




2
Origines
       Issus des travaux de l'architecte Christopher Alexander
        (patrons en architecture des bâtiments)
       1995: Parution du livre "Design Patterns -- Elements of
        Reusable Object-Oriented Software",
           Gang Of Four (Erich Gamma, Richard Helm, Ralph Johnson et
            John Vlissides),
           Présente 23 Design Patterns




    3
Qui suis je?
       Eric Joël TOGUEM
           CIO à AByster Inc.
           Leader de CamerJUG,
           Certifications: OCPJP 6, OCEJPAD6,
           eric.toguem@abyster.com




4
Design Pattern?
       Description d'une solution à un problème de conception
       "Prouvé » s'il a pu être utilisé dans au moins 3 cas
       Permettent d'améliorer la qualité de développement et
        d'en diminuer la durée




    5
Design Pattern: 3 catégories
       Créationnels : Définissent des mécanismes pour
        l'instanciation et/ou l'initialisation d'objets
       Structuraux : Organisent les interfaces/classes entre
        elles
       Comportementaux : Définissent la communication
        entre les classes et leurs responsabilités




    6
Design pattern créationnels

    Définissent des mécanismes pour l'instanciation et/ou
                    l'initialisation d'objets




7
5 design patterns créationnels
       Fabrique Abstraite: Isole l'appartenance à une famille
        de classes
       Monteur: Isole les variations de représentations d'un
        objet
       Fabrique: Isole l'instanciation d'une classe concrète
       Prototype: Isole l'appartenance à une classe
       Singleton: Isole l'unicité d'une instance.




    8
Fabrique Abstraite (Abstract factory)
       Objectif: Fournir une interface pour créer des objets
        d'une même famille sans préciser leurs classes concrètes.
       Quand Utiliser: Le système utilise des objets qui sont
        regroupés en famille.
       Exemple: pour un look and feel donné, tous les
        graphiques créés doivent être de la même famille
       Résultat : Isole l'appartenance à une famille de classes.




    9
Fabrique Abstraite (Abstract factory)




10
Monteur (Builder)
    Objectifs:
        Séparer la construction d'un objet complexe de sa
         représentation.
        Permettre d'obtenir des représentations différentes avec le
         même procédé de construction.
    Quand Utiliser: Le système doit instancier des objets
     complexes,
    Exemple: Différentes fenêtres d’une IHM,
    Résultat: Isole les variations de représentations d'un
     objet


    11
Monteur (Builder)




12
Fabrique (Factory Method)
    Objectifs: Déléguer l'instanciation aux sous-classes.
    Quand Utiliser: Au niveau d’une classe, on ne connaît
     pas la classe exacte à instancier,
    Exemple: Classe réalisant une sauvegarde dans un flux
     sortant, mais ne sachant pas s'il s'agit d'un fichier ou d'une
     sortie sur le réseau,
    Résultat: Isole l'instanciation d'une classe concrète.




    13
Fabrique (Factory Method)




14
Prototype (Prototype)
    Objectifs: Créer un nouvel objet à partir d’un
     prototype.
    Quand Utiliser: Le système doit créer de nouvelles
     instances, mais il ignore de quelle classe. Il dispose
     cependant d'instances de la classe désirée.
    Exemple: Cas d'un logiciel de DAO comportant un
     copier-coller,
    Résultat: Isole l'appartenance à une classe.




    15
Prototype (Prototype)




16
Singleton (Singleton)
    Objectifs
        Restreindre le nombre d' instances d'une classe à une seule.
        Fournir une méthode pour accéder à cette instance unique.
    Quand Utiliser: La classe ne doit avoir qu'une seule
     instance.
    Exemple: Cas d'une ressource système,
    Résultat: Isole l'unicité d'une instance.




    17
Singleton (Singleton)




18
Designs pattern structuraux

          Organisent les interfaces/classes entre elles




19
7 designs pattern structuraux
    Adaptateur: Convertir l'interface d'une classe dans une autre
     interface comprise par la partie cliente
    Pont: Découpler l'abstraction d'un concept de son
     implémentation
    Composite: Permettre à la partie cliente de manipuler un
     objet unique et un objet composé de la même manière
    Décorateur: Ajouter dynamiquement des responsabilités à
     un objet
    Façade: Fournir une interface unique en remplacement d'un
     ensemble d'interfaces d'un sous-système
    Poids-Mouche: Utiliser le partage pour gérer efficacement un
     grand nombre d'objets de faible granularité
    Proxy: Fournir un intermédiaire entre la partie cliente et un
     objet pour contrôler les accès à ce dernier

    20
Adaptateur (Adapter ou Wrapper)
    Objectifs: Convertir l'interface d'une classe dans une
     autre interface comprise par la partie cliente.
    Quand Utiliser: Le système doit intégrer un sous-
     système existant. Ce sous-système a une interface non
     standard par rapport au système.
    Exemple: Cas d’un driver bas niveau fournit par le
     fabricant ne correspondant pas à l'interface utilisée par le
     système pour d'autres drivers.
    Résultat: Isole l'adaptation d'un sous-système.



    21
Adaptateur (Adapter ou Wrapper)




22
Pont (Bridge ou Handle/Body)
    Objectifs: Découpler l'abstraction d'un concept de son
     implémentation.
    Quand Utiliser: Le système comporte une couche bas
     niveau réalisant l'implémentation et une couche haut niveau
     réalisant l'abstraction. Il est nécessaire que chaque couche soit
     indépendante.
    Exemple: Système d'édition de documents d'une application.
     Pour l'implémentation, l'édition aboutit à une sortie
     imprimante, une image sur disque, un document PDF, etc. Pour
     l'abstraction, il s'agit d'édition de factures, de rapports de stock
     ou de courriers divers.
    Résultat: Isole le lien entre une couche de haut niveau et
     celle de bas niveau.

    23
Pont (Bridge ou Handle/Body)




24
Composite (Composite)
    Objectifs: Permettre à la partie cliente de manipuler un
     objet unique et un objet composé de la même manière.
    Quand Utiliser: Le système comporte une hiérarchie
     avec un nombre de niveaux non déterminé. Il faut pouvoir
     considérer un groupe d'éléments comme un élément
     unique.
    Exemple: Logiciel de DAO, plusieurs éléments
     graphiques peuvent être regroupés en un nouvel élément
     graphique.
    Résultat: Isole l'appartenance à un agrégat.


    25
Composite (Composite)




26
Décorateur (Decorator ou Wrapper)
    Objectifs: Ajouter dynamiquement des responsabilités à
     un objet.
    Quand Utiliser: Il est nécessaire de pouvoir étendre les
     responsabilités d'une classe sans avoir recours au sous-
     classage.
    Exemple: Cas d'une classe gérant des d'entrées/sorties à
     laquelle on souhaite ajouter un buffer et des traces de
     log.
    Résultat: Isole les responsabilités d'un objet.



    27
Décorateur (Decorator ou Wrapper)




28
Façade (Facade)
    Objectifs: Fournir une interface unique en remplacement
     d'un ensemble d'interfaces d'un sous-système.
    Quand Utiliser: Le système comporte un sous-système
     complexe avec plusieurs interfaces, certaines présentant
     des opérations pas utiles au reste du système.
    Exemple: Cas d'un sous-système communiquant avec
     des outils de mesure.
    Résultat: Isole les fonctionnalités d'un sous-système
     utiles à la partie cliente.



    29
Façade (Facade)




30
Poids-Mouche (Flyweight)
    Objectifs: Utiliser le partage pour gérer efficacement un
     grand nombre d'objets de faible granularité.
    Quand Utiliser: Un système utilise un grand nombre d'
     instances. Chacune de ces instances a des attributs
     propre au contexte et propre à l'objet.
    Exemple: Cas caractéristiques des traits dans un logiciel
     de DAO. Les caractéristiques d'épaisseur, d'ombre sont
     intrinsèques, et les coordonnées sont extrinsèques.
    Résultat: Isole les propriétés partageables des objets.



    31
Poids-Mouche (Flyweight)




32
Proxy (Proxy ou Surrogate)
    Objectifs: Fournir un intermédiaire entre la partie
     cliente et un objet pour contrôler les accès à ce dernier.
    Quand Utiliser: Les opérations d'un objet sont
     coûteuses en temps ou sont soumises à une gestion de
     droits d'accès.
    Exemple: Cela peut être un système de chargement d'un
     document (gestion droits d’accès).
    Résultat: Isole le comportement lors de l'accès à un
     objet.



    33
Proxy (Proxy ou Surrogate)




34
Design patterns
                            Comportementaux
     Définissent la communication entre les classes et leurs
                        responsabilités




35
11 design patterns Comportementaux
(1/2)
    Chaîne de responsabilité: Eviter le couplage entre l'
     émetteur d'une requête et son récepteur en donnant à plus
     d'un objet une chance de traiter la requête
    Commande : Paramétrer facilement des requêtes diverses.
    Interpréteur : Définir une représentation de la grammaire
     d'un langage.
    Itérateur : Fournir un moyen de parcourir séquentiellement
     les éléments d'un objet composé.
    Médiateur : Gérer la transmission d'informations entre des
     objets interagissant entre eux
    Memento : Sauvegarder l' état interne d'un objet en
     respectant l' encapsulation, afin de le restaurer plus tard.

    36
11 design patterns Comportementaux
(2/2)
    Observateur : Prévenir des objets observateurs,
     enregistrés auprès d'un objet observé, d'un événement
    Etat : Changer le comportement d'un objet selon son
     état interne.
    Stratégie : Définir une famille d' algorithmes
     interchangeables, indépendamment de la partie cliente.
    Patron de méthode : Définir le squelette d'un
     algorithme en déléguant certaines étapes à des sous-
     classes.
    Visiteur : Séparer un algorithme d'une structure de
     données.

    37
Chaîne de responsabilité (Chain of
responsibility)
    Objectifs: Eviter le couplage entre l' émetteur d'une
     requête et son récepteur en donnant à plus d'un objet
     une chance de traiter la requête.
    Quand Utiliser: Le système doit gérer un requête. La
     requête implique plusieurs objets pour la traiter.
    Exemple: Cas d'un système complexe d'habilitations
     possédant plusieurs critères afin d'autoriser l'accès. Ces
     critères peuvent varier en fonction de la configuration.
    Résultat: Isole les différentes parties d'un traitement.



    38
Chaîne de responsabilité (Chain of
responsibility)




39
Commande (Command, Action ou
Transaction)
    Objectifs:
        Encapsuler une requête sous la forme d' objet.
        Paramétrer facilement des requêtes diverses.
        Permettre des opérations réversibles
    Quand Utiliser: Le système doit traiter des requêtes,
     pouvant provenir de plusieurs émetteurs et pouvant être
     annulées.
    Exemple: cas d'une IHM avec des boutons de
     commande, des raccourcis clavier et des choix de menu
     aboutissant à la même requête.
    Résultat: Isole une requête.

    40
Commande (Command, Action ou
Transaction)




41
Interpréteur (Interpreter)
    Objectifs:
        Définir une représentation de la grammaire d'un langage.
        Utiliser cette représentation pour interpréter les éléments de
         ce langage.
    Quand Utiliser: Le système doit interpréter un langage.
    Exemple: Cas d'un logiciel embarqué dont la
     configuration des écrans serait stockée dans des fichiers
     XML.
    Résultat: Isole les éléments d'un langage.



    42
Interpréteur (Interpreter)




43
Itérateur (Iterator ou Cursor)
    Objectifs: Fournir un moyen de parcourir
     séquentiellement les éléments d'un objet composé.
    Quand Utiliser: Le système doit parcourir les éléments
     d'un objet complexe,
    Exemple: Cas des classes représentant des listes et des
     ensembles en Java.
    Résultat: Isole le parcours d'un agrégat.




    44
Itérateur (Iterator ou Cursor)




45
Médiateur (Mediator)
    Objectifs: Gérer la transmission d'informations entre
     des objets interagissant entre eux.
    Quand Utiliser: Différents objets ont des interactions.
     Un événement sur l'un provoque une (ou des) action(s)
     sur un (ou d‘)autre(s) objets,
    Exemple: Cas des éléments d'IHM. Si une case est
     cochée, certains éléments deviennent accessibles.
    Résultat: Isole la communication entre des objets.




    46
Médiateur (Mediator)




47
Memento (Memento)
    Objectifs: Sauvegarder l' état interne d'un objet en
     respectant l' encapsulation, afin de le restaurer plus tard.
    Quand Utiliser: Un système doit conserver et restaurer
     l'état d'un objet. L'état interne de l'objet à conserver n'est
     pas visible par les autres objets.
    Exemple: Cas d’un éditeur de document disposant d'une
     fonction d'annulation
    Résultat: Isole la conservation de l'état d'un objet.




    48
Memento (Memento)




La partie cliente demande au Createur de stocker son état dans un Memento. Elle
demande au Gardien de conserver ce Memento. Elle peut alors demander au Gardien de
lui fournir un des Memento conservés, ou bien elle demande au Createur de restituer
   49
son état depuis le Memento.
Observateur (Observer)
    Objectifs: Prévenir des objets observateurs, enregistrés
     auprès d'un objet observé, d'un événement.
    Quand Utiliser: Un objet doit connaitre les
     changements d' état d'un autre objet. L'objet doit être
     informé immédiatement.
    Exemple: Cas d'un tableau affichant des statistiques. Si
     une nouvelle donnée est entrée, les statistiques sont
     recalculées
    Résultat: Isole un algorithme traitant un événement.



    50
Observateur (Observer)




La partie cliente indique à l'objet Observe les objets Observateur qu'il avertira.



   51
Etat (State)
    Objectifs: Changer le comportement d'un objet selon
     son état interne.
    Quand Utiliser: Un objet a un fonctionnement différent
     selon son état interne.
    Exemple: Cas d’un document informatique. Il a comme
     fonctions ouvrir, modifier. Le comportement de ces
     méthodes change selon l'état du document
    Résultat: Isole les algorithmes propres à chaque état
     d'un objet.



    52
Etat (State)




53
Stratégie (Strategy)
    Objectifs: Définir une famille d' algorithmes
     interchangeables, indépendamment de la partie cliente.
    Quand Utiliser: Un objet doit pouvoir faire varier une
     partie de son algorithme.
    Exemple: Cas d’un Cela peut être une liste triée. Le tri
     peut être alphabétique, inverse, les majuscules avant les
     miniscules, …
    Résultat: Isole les algorithmes appartenant à une même
     famille d'algorithmes.



    54
Stratégie (Strategy)




La partie cliente configure un objet ClasseUtilisantStrategie avec un objet Strategie
    55
et appelle la méthode de ClasseUtilisantStrategie qui utilise la stratégie.
Patron de méthode (Template method)
    Objectifs: Définir le squelette d'un algorithme en
     déléguant certaines étapes à des sous-classes.
    Quand Utiliser: Une classe possède un fonctionnement
     global. Mais les détails de son algorithme doivent être
     spécifiques à ses sous-classes.
    Exemple: Cas d'un document informatique qui peut être
     sauvegardé. Selon le type de document, il ne sera pas
     sauvegardé de la même manière, …
    Résultat: Isole les parties variables d'un algorithme.



    56
Patron de méthode (Template method)




La partie cliente appelle la méthode de AbstractClasse qui définit l'algorithme
   57
Visiteur (Visitor)
    Objectifs: Séparer un algorithme d'une structure de
     données.
    Quand Utiliser: Il est nécessaire de réaliser des
     opérations, sur les éléments d'un objet structuré, qui
     varient en fonction de la nature de chaque élément et
     peuvent être de plusieurs types.
    Exemple: Cas d'un logiciel d'images de synthèse. L'image
     composée de plusieurs objets : sphère, polygone, etc... Sur
     chaque élément, il faut effectuer plusieurs opérations
     pour le rendu : ajout des couleurs, effet d'éclairage, …
    Résultat: Isole les algorithmes appliquées sur des
     structures de données

    58
Visiteur (Visitor)




La partie cliente appelle les méthodes de réception d'un Visiteur des Element.
   59
Références
    http://rpouiller.developpez.com/tutoriel/java/design-
     patterns-gang-of-four/
    Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
     (trad. Jean-Marie Lasvergères), Design Patterns - Catalogue
     de modèles de conceptions réutilisables




    60

Contenu connexe

Tendances

Architectures n-tiers
Architectures n-tiersArchitectures n-tiers
Architectures n-tiersHeithem Abbes
 
Applications Android - cours 7 : Ressources et adaptation au matériel
Applications Android - cours 7 : Ressources et adaptation au matérielApplications Android - cours 7 : Ressources et adaptation au matériel
Applications Android - cours 7 : Ressources et adaptation au matérielAhmed-Chawki Chaouche
 
Applications Android - cours 12 : Persistance de données SQLite
Applications Android - cours 12 : Persistance de données SQLiteApplications Android - cours 12 : Persistance de données SQLite
Applications Android - cours 12 : Persistance de données SQLiteAhmed-Chawki Chaouche
 
Architectures orientés services (SOA)
Architectures orientés services (SOA)Architectures orientés services (SOA)
Architectures orientés services (SOA)Heithem Abbes
 
exercices Corrigées du merise
exercices Corrigées du  meriseexercices Corrigées du  merise
exercices Corrigées du meriseYassine Badri
 
Cours design pattern m youssfi partie 8 stat, template method, command , medi...
Cours design pattern m youssfi partie 8 stat, template method, command , medi...Cours design pattern m youssfi partie 8 stat, template method, command , medi...
Cours design pattern m youssfi partie 8 stat, template method, command , medi...ENSET, Université Hassan II Casablanca
 
Tp1 - Initiation à Java-Eclipse
Tp1 - Initiation à Java-EclipseTp1 - Initiation à Java-Eclipse
Tp1 - Initiation à Java-EclipseLilia Sfaxi
 
Architectures 3-tiers (Web)
Architectures 3-tiers (Web)Architectures 3-tiers (Web)
Architectures 3-tiers (Web)Heithem Abbes
 
Exercices uml-corrige
Exercices uml-corrigeExercices uml-corrige
Exercices uml-corrigeAmineMouhout1
 
base de données -note de cours
base de données -note de cours base de données -note de cours
base de données -note de cours Yassine Badri
 
Tp1 - WS avec JAXWS
Tp1 - WS avec JAXWSTp1 - WS avec JAXWS
Tp1 - WS avec JAXWSLilia Sfaxi
 
Manuel des TP : Atelier Web 2
Manuel des TP : Atelier Web 2Manuel des TP : Atelier Web 2
Manuel des TP : Atelier Web 2Faycel Chaoua
 

Tendances (20)

Architectures n-tiers
Architectures n-tiersArchitectures n-tiers
Architectures n-tiers
 
Support Java Avancé Troisième Partie
Support Java Avancé Troisième PartieSupport Java Avancé Troisième Partie
Support Java Avancé Troisième Partie
 
Applications Android - cours 7 : Ressources et adaptation au matériel
Applications Android - cours 7 : Ressources et adaptation au matérielApplications Android - cours 7 : Ressources et adaptation au matériel
Applications Android - cours 7 : Ressources et adaptation au matériel
 
Applications Android - cours 12 : Persistance de données SQLite
Applications Android - cours 12 : Persistance de données SQLiteApplications Android - cours 12 : Persistance de données SQLite
Applications Android - cours 12 : Persistance de données SQLite
 
Architectures orientés services (SOA)
Architectures orientés services (SOA)Architectures orientés services (SOA)
Architectures orientés services (SOA)
 
exercices Corrigées du merise
exercices Corrigées du  meriseexercices Corrigées du  merise
exercices Corrigées du merise
 
Cours design pattern m youssfi partie 3 decorateur
Cours design pattern m youssfi partie 3 decorateurCours design pattern m youssfi partie 3 decorateur
Cours design pattern m youssfi partie 3 decorateur
 
Modélisation avec UML
Modélisation avec UMLModélisation avec UML
Modélisation avec UML
 
Cours design pattern m youssfi partie 8 stat, template method, command , medi...
Cours design pattern m youssfi partie 8 stat, template method, command , medi...Cours design pattern m youssfi partie 8 stat, template method, command , medi...
Cours design pattern m youssfi partie 8 stat, template method, command , medi...
 
Tp1 - Initiation à Java-Eclipse
Tp1 - Initiation à Java-EclipseTp1 - Initiation à Java-Eclipse
Tp1 - Initiation à Java-Eclipse
 
Architectures 3-tiers (Web)
Architectures 3-tiers (Web)Architectures 3-tiers (Web)
Architectures 3-tiers (Web)
 
Exercices uml-corrige
Exercices uml-corrigeExercices uml-corrige
Exercices uml-corrige
 
base de données -note de cours
base de données -note de cours base de données -note de cours
base de données -note de cours
 
Cours design pattern m youssfi partie 5 adapter
Cours design pattern m youssfi partie 5 adapterCours design pattern m youssfi partie 5 adapter
Cours design pattern m youssfi partie 5 adapter
 
Tp1 - WS avec JAXWS
Tp1 - WS avec JAXWSTp1 - WS avec JAXWS
Tp1 - WS avec JAXWS
 
Spring ioc
Spring iocSpring ioc
Spring ioc
 
Patrons de conception
Patrons de conceptionPatrons de conception
Patrons de conception
 
Chp4 - UML
Chp4 - UMLChp4 - UML
Chp4 - UML
 
Manuel des TP : Atelier Web 2
Manuel des TP : Atelier Web 2Manuel des TP : Atelier Web 2
Manuel des TP : Atelier Web 2
 
Support POO Java première partie
Support POO Java première partieSupport POO Java première partie
Support POO Java première partie
 

En vedette

Atouts et limites du modèle de management anglo-saxon
Atouts et limites du modèle de management anglo-saxonAtouts et limites du modèle de management anglo-saxon
Atouts et limites du modèle de management anglo-saxonLe Rendez Vous
 
Voici les 34 technologies de 2016 à forts enjeux stratégiques selon Gartner
Voici les 34 technologies de 2016 à forts enjeux stratégiques selon GartnerVoici les 34 technologies de 2016 à forts enjeux stratégiques selon Gartner
Voici les 34 technologies de 2016 à forts enjeux stratégiques selon GartnerThibaut Watrigant
 
Les rendez-vous de l’INRA - L'Europe Laitière en 2020 : bilan, perspectives e...
Les rendez-vous de l’INRA - L'Europe Laitière en 2020 : bilan, perspectives e...Les rendez-vous de l’INRA - L'Europe Laitière en 2020 : bilan, perspectives e...
Les rendez-vous de l’INRA - L'Europe Laitière en 2020 : bilan, perspectives e...Institut de l'Elevage - Idele
 
Caractéristiques et opportunités de la vente alimentaire via Internet
Caractéristiques et opportunités de la vente alimentaire via InternetCaractéristiques et opportunités de la vente alimentaire via Internet
Caractéristiques et opportunités de la vente alimentaire via InternetQualivore Midi-pyrenees
 
Panorama 2013 du Business Process Management : Le BPM en marche
Panorama 2013 du Business Process Management : Le BPM en marchePanorama 2013 du Business Process Management : Le BPM en marche
Panorama 2013 du Business Process Management : Le BPM en marcheEY
 
Tour d'horizon du F-commerce - Barcamp e commerce juin 2011
Tour d'horizon du F-commerce - Barcamp e commerce juin 2011Tour d'horizon du F-commerce - Barcamp e commerce juin 2011
Tour d'horizon du F-commerce - Barcamp e commerce juin 2011Boosket
 
Le métier insolite - Photographe sous-marin
Le métier insolite - Photographe sous-marinLe métier insolite - Photographe sous-marin
Le métier insolite - Photographe sous-marinevilagines
 
Cp ecole des metiers du drone pixiel-13 avril2015[1]
Cp ecole des metiers du drone pixiel-13 avril2015[1]Cp ecole des metiers du drone pixiel-13 avril2015[1]
Cp ecole des metiers du drone pixiel-13 avril2015[1]Esperluette & Associés
 
Drone Hacking - Qualitek Security Day 2014
Drone Hacking - Qualitek Security Day 2014Drone Hacking - Qualitek Security Day 2014
Drone Hacking - Qualitek Security Day 2014Eduardo Barros Santos
 
Sous-marin nucléaire lanceur d'engins
Sous-marin nucléaire lanceur d'enginsSous-marin nucléaire lanceur d'engins
Sous-marin nucléaire lanceur d'enginsjufanch
 
D'autres modèles d'accès ouvert sont possibles | Marin Dacos, Paris, 23 jan...
D'autres modèles d'accès ouvert sont possibles | Marin Dacos, Paris, 23 jan...D'autres modèles d'accès ouvert sont possibles | Marin Dacos, Paris, 23 jan...
D'autres modèles d'accès ouvert sont possibles | Marin Dacos, Paris, 23 jan...OpenEdition
 
La médiation du patrimoine sous-marin
La médiation du patrimoine sous-marinLa médiation du patrimoine sous-marin
La médiation du patrimoine sous-marincirili_web
 
Interação além da tela: design de aplicações para as próximas gerações (JATIC)
Interação além da tela: design de aplicações para as próximas gerações� (JATIC)Interação além da tela: design de aplicações para as próximas gerações� (JATIC)
Interação além da tela: design de aplicações para as próximas gerações (JATIC)Tatiana Tavares
 
TDC2015 - Um drone para chamar de seu
TDC2015 - Um drone para chamar de seuTDC2015 - Um drone para chamar de seu
TDC2015 - Um drone para chamar de seuOdair Bonin Borges
 
DroneLab : a oficina de Drones
DroneLab : a oficina de DronesDroneLab : a oficina de Drones
DroneLab : a oficina de DronesOdair Bonin Borges
 

En vedette (20)

Atouts et limites du modèle de management anglo-saxon
Atouts et limites du modèle de management anglo-saxonAtouts et limites du modèle de management anglo-saxon
Atouts et limites du modèle de management anglo-saxon
 
Voici les 34 technologies de 2016 à forts enjeux stratégiques selon Gartner
Voici les 34 technologies de 2016 à forts enjeux stratégiques selon GartnerVoici les 34 technologies de 2016 à forts enjeux stratégiques selon Gartner
Voici les 34 technologies de 2016 à forts enjeux stratégiques selon Gartner
 
Les rendez-vous de l’INRA - L'Europe Laitière en 2020 : bilan, perspectives e...
Les rendez-vous de l’INRA - L'Europe Laitière en 2020 : bilan, perspectives e...Les rendez-vous de l’INRA - L'Europe Laitière en 2020 : bilan, perspectives e...
Les rendez-vous de l’INRA - L'Europe Laitière en 2020 : bilan, perspectives e...
 
Caractéristiques et opportunités de la vente alimentaire via Internet
Caractéristiques et opportunités de la vente alimentaire via InternetCaractéristiques et opportunités de la vente alimentaire via Internet
Caractéristiques et opportunités de la vente alimentaire via Internet
 
Bora Bora
Bora BoraBora Bora
Bora Bora
 
Panorama 2013 du Business Process Management : Le BPM en marche
Panorama 2013 du Business Process Management : Le BPM en marchePanorama 2013 du Business Process Management : Le BPM en marche
Panorama 2013 du Business Process Management : Le BPM en marche
 
Tour d'horizon du F-commerce - Barcamp e commerce juin 2011
Tour d'horizon du F-commerce - Barcamp e commerce juin 2011Tour d'horizon du F-commerce - Barcamp e commerce juin 2011
Tour d'horizon du F-commerce - Barcamp e commerce juin 2011
 
Le métier insolite - Photographe sous-marin
Le métier insolite - Photographe sous-marinLe métier insolite - Photographe sous-marin
Le métier insolite - Photographe sous-marin
 
Cv
CvCv
Cv
 
Cp ecole des metiers du drone pixiel-13 avril2015[1]
Cp ecole des metiers du drone pixiel-13 avril2015[1]Cp ecole des metiers du drone pixiel-13 avril2015[1]
Cp ecole des metiers du drone pixiel-13 avril2015[1]
 
Drone Hacking - Qualitek Security Day 2014
Drone Hacking - Qualitek Security Day 2014Drone Hacking - Qualitek Security Day 2014
Drone Hacking - Qualitek Security Day 2014
 
Sous-marin nucléaire lanceur d'engins
Sous-marin nucléaire lanceur d'enginsSous-marin nucléaire lanceur d'engins
Sous-marin nucléaire lanceur d'engins
 
D'autres modèles d'accès ouvert sont possibles | Marin Dacos, Paris, 23 jan...
D'autres modèles d'accès ouvert sont possibles | Marin Dacos, Paris, 23 jan...D'autres modèles d'accès ouvert sont possibles | Marin Dacos, Paris, 23 jan...
D'autres modèles d'accès ouvert sont possibles | Marin Dacos, Paris, 23 jan...
 
Einparkhilfe Präsentation
Einparkhilfe PräsentationEinparkhilfe Präsentation
Einparkhilfe Präsentation
 
La médiation du patrimoine sous-marin
La médiation du patrimoine sous-marinLa médiation du patrimoine sous-marin
La médiation du patrimoine sous-marin
 
Interação além da tela: design de aplicações para as próximas gerações (JATIC)
Interação além da tela: design de aplicações para as próximas gerações� (JATIC)Interação além da tela: design de aplicações para as próximas gerações� (JATIC)
Interação além da tela: design de aplicações para as próximas gerações (JATIC)
 
Carlos 8ºb
Carlos 8ºbCarlos 8ºb
Carlos 8ºb
 
Hackeando drones com Software Livre
Hackeando drones com Software LivreHackeando drones com Software Livre
Hackeando drones com Software Livre
 
TDC2015 - Um drone para chamar de seu
TDC2015 - Um drone para chamar de seuTDC2015 - Um drone para chamar de seu
TDC2015 - Um drone para chamar de seu
 
DroneLab : a oficina de Drones
DroneLab : a oficina de DronesDroneLab : a oficina de Drones
DroneLab : a oficina de Drones
 

Similaire à Design patterns

Patrons de creation
Patrons de creationPatrons de creation
Patrons de creationomri med
 
Design patterns - Exemples en Java
Design patterns - Exemples en JavaDesign patterns - Exemples en Java
Design patterns - Exemples en JavaOussama BEN KHIROUN
 
DesignPatternsISI.pdf
DesignPatternsISI.pdfDesignPatternsISI.pdf
DesignPatternsISI.pdfandre543581
 
Design patterns gof fr
Design patterns gof frDesign patterns gof fr
Design patterns gof frIt Academy
 
Support de cours Conception orientée objets - partie 1.pdf
Support de cours Conception orientée objets - partie 1.pdfSupport de cours Conception orientée objets - partie 1.pdf
Support de cours Conception orientée objets - partie 1.pdfYasushiTsubakik
 
Cours partie1 elgarrai zineb
Cours partie1 elgarrai zinebCours partie1 elgarrai zineb
Cours partie1 elgarrai zinebZineb ELGARRAI
 
UML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouriUML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouriMansouri Khalifa
 
Design patterns french
Design patterns frenchDesign patterns french
Design patterns frenchmeriem sari
 
Entity_framework_db first
Entity_framework_db firstEntity_framework_db first
Entity_framework_db firstZineb ELGARRAI
 
Diagramme de-composants152
Diagramme de-composants152Diagramme de-composants152
Diagramme de-composants152Sirafina Rosa
 
Introduction à l'objet - Deuxième année ISIMA
Introduction à l'objet - Deuxième année ISIMAIntroduction à l'objet - Deuxième année ISIMA
Introduction à l'objet - Deuxième année ISIMALoic Yon
 
OOP & Design Pattern - Algiers Developers Meetup August 2015
OOP & Design Pattern - Algiers Developers Meetup August 2015OOP & Design Pattern - Algiers Developers Meetup August 2015
OOP & Design Pattern - Algiers Developers Meetup August 2015Tarik Zakaria Benmerar
 
Design Patterns Java
Design Patterns JavaDesign Patterns Java
Design Patterns JavaVINOT Bernard
 
Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]linasafaa
 
PROGRAMMATION 2e GENIE PARTIE THEORIE.ppt
PROGRAMMATION 2e GENIE PARTIE THEORIE.pptPROGRAMMATION 2e GENIE PARTIE THEORIE.ppt
PROGRAMMATION 2e GENIE PARTIE THEORIE.pptEddySHANGA
 

Similaire à Design patterns (20)

Patrons de creation
Patrons de creationPatrons de creation
Patrons de creation
 
Design patterns - Exemples en Java
Design patterns - Exemples en JavaDesign patterns - Exemples en Java
Design patterns - Exemples en Java
 
DesignPatternsISI.pdf
DesignPatternsISI.pdfDesignPatternsISI.pdf
DesignPatternsISI.pdf
 
Abstract factory+adapter
Abstract factory+adapterAbstract factory+adapter
Abstract factory+adapter
 
Design patterns gof fr
Design patterns gof frDesign patterns gof fr
Design patterns gof fr
 
POO-Cours.pdf
POO-Cours.pdfPOO-Cours.pdf
POO-Cours.pdf
 
Support de cours Conception orientée objets - partie 1.pdf
Support de cours Conception orientée objets - partie 1.pdfSupport de cours Conception orientée objets - partie 1.pdf
Support de cours Conception orientée objets - partie 1.pdf
 
Cours partie1 elgarrai zineb
Cours partie1 elgarrai zinebCours partie1 elgarrai zineb
Cours partie1 elgarrai zineb
 
UML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouriUML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouri
 
Design patterns french
Design patterns frenchDesign patterns french
Design patterns french
 
Qualité de code et bonnes pratiques
Qualité de code et bonnes pratiquesQualité de code et bonnes pratiques
Qualité de code et bonnes pratiques
 
Entity_framework_db first
Entity_framework_db firstEntity_framework_db first
Entity_framework_db first
 
Diagramme de-composants152
Diagramme de-composants152Diagramme de-composants152
Diagramme de-composants152
 
Introduction à l'objet - Deuxième année ISIMA
Introduction à l'objet - Deuxième année ISIMAIntroduction à l'objet - Deuxième année ISIMA
Introduction à l'objet - Deuxième année ISIMA
 
OOP and Design Patterns
OOP and Design PatternsOOP and Design Patterns
OOP and Design Patterns
 
OOP & Design Pattern - Algiers Developers Meetup August 2015
OOP & Design Pattern - Algiers Developers Meetup August 2015OOP & Design Pattern - Algiers Developers Meetup August 2015
OOP & Design Pattern - Algiers Developers Meetup August 2015
 
Design Patterns Java
Design Patterns JavaDesign Patterns Java
Design Patterns Java
 
Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]
 
PROGRAMMATION 2e GENIE PARTIE THEORIE.ppt
PROGRAMMATION 2e GENIE PARTIE THEORIE.pptPROGRAMMATION 2e GENIE PARTIE THEORIE.ppt
PROGRAMMATION 2e GENIE PARTIE THEORIE.ppt
 
Generateur de code java (GenJAVA)
Generateur de code java (GenJAVA)Generateur de code java (GenJAVA)
Generateur de code java (GenJAVA)
 

Plus de Eric Toguem

Les nouveautés de java 7 et les promesses
Les nouveautés de java 7  et les promessesLes nouveautés de java 7  et les promesses
Les nouveautés de java 7 et les promessesEric Toguem
 
Linked open data pour la consommation des informations
Linked open data pour la consommation des informationsLinked open data pour la consommation des informations
Linked open data pour la consommation des informationsEric Toguem
 
Plateformes de développement d’applications mobiles
Plateformes de développement d’applications mobilesPlateformes de développement d’applications mobiles
Plateformes de développement d’applications mobilesEric Toguem
 
Développement d’applications ussd en java
Développement d’applications ussd en javaDéveloppement d’applications ussd en java
Développement d’applications ussd en javaEric Toguem
 
Introspection reflection
Introspection reflectionIntrospection reflection
Introspection reflectionEric Toguem
 
Les expressions régulières en java
Les expressions régulières en javaLes expressions régulières en java
Les expressions régulières en javaEric Toguem
 

Plus de Eric Toguem (6)

Les nouveautés de java 7 et les promesses
Les nouveautés de java 7  et les promessesLes nouveautés de java 7  et les promesses
Les nouveautés de java 7 et les promesses
 
Linked open data pour la consommation des informations
Linked open data pour la consommation des informationsLinked open data pour la consommation des informations
Linked open data pour la consommation des informations
 
Plateformes de développement d’applications mobiles
Plateformes de développement d’applications mobilesPlateformes de développement d’applications mobiles
Plateformes de développement d’applications mobiles
 
Développement d’applications ussd en java
Développement d’applications ussd en javaDéveloppement d’applications ussd en java
Développement d’applications ussd en java
 
Introspection reflection
Introspection reflectionIntrospection reflection
Introspection reflection
 
Les expressions régulières en java
Les expressions régulières en javaLes expressions régulières en java
Les expressions régulières en java
 

Design patterns

  • 3. Origines  Issus des travaux de l'architecte Christopher Alexander (patrons en architecture des bâtiments)  1995: Parution du livre "Design Patterns -- Elements of Reusable Object-Oriented Software",  Gang Of Four (Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides),  Présente 23 Design Patterns 3
  • 4. Qui suis je?  Eric Joël TOGUEM  CIO à AByster Inc.  Leader de CamerJUG,  Certifications: OCPJP 6, OCEJPAD6,  eric.toguem@abyster.com 4
  • 5. Design Pattern?  Description d'une solution à un problème de conception  "Prouvé » s'il a pu être utilisé dans au moins 3 cas  Permettent d'améliorer la qualité de développement et d'en diminuer la durée 5
  • 6. Design Pattern: 3 catégories  Créationnels : Définissent des mécanismes pour l'instanciation et/ou l'initialisation d'objets  Structuraux : Organisent les interfaces/classes entre elles  Comportementaux : Définissent la communication entre les classes et leurs responsabilités 6
  • 7. Design pattern créationnels Définissent des mécanismes pour l'instanciation et/ou l'initialisation d'objets 7
  • 8. 5 design patterns créationnels  Fabrique Abstraite: Isole l'appartenance à une famille de classes  Monteur: Isole les variations de représentations d'un objet  Fabrique: Isole l'instanciation d'une classe concrète  Prototype: Isole l'appartenance à une classe  Singleton: Isole l'unicité d'une instance. 8
  • 9. Fabrique Abstraite (Abstract factory)  Objectif: Fournir une interface pour créer des objets d'une même famille sans préciser leurs classes concrètes.  Quand Utiliser: Le système utilise des objets qui sont regroupés en famille.  Exemple: pour un look and feel donné, tous les graphiques créés doivent être de la même famille  Résultat : Isole l'appartenance à une famille de classes. 9
  • 11. Monteur (Builder)  Objectifs:  Séparer la construction d'un objet complexe de sa représentation.  Permettre d'obtenir des représentations différentes avec le même procédé de construction.  Quand Utiliser: Le système doit instancier des objets complexes,  Exemple: Différentes fenêtres d’une IHM,  Résultat: Isole les variations de représentations d'un objet 11
  • 13. Fabrique (Factory Method)  Objectifs: Déléguer l'instanciation aux sous-classes.  Quand Utiliser: Au niveau d’une classe, on ne connaît pas la classe exacte à instancier,  Exemple: Classe réalisant une sauvegarde dans un flux sortant, mais ne sachant pas s'il s'agit d'un fichier ou d'une sortie sur le réseau,  Résultat: Isole l'instanciation d'une classe concrète. 13
  • 15. Prototype (Prototype)  Objectifs: Créer un nouvel objet à partir d’un prototype.  Quand Utiliser: Le système doit créer de nouvelles instances, mais il ignore de quelle classe. Il dispose cependant d'instances de la classe désirée.  Exemple: Cas d'un logiciel de DAO comportant un copier-coller,  Résultat: Isole l'appartenance à une classe. 15
  • 17. Singleton (Singleton)  Objectifs  Restreindre le nombre d' instances d'une classe à une seule.  Fournir une méthode pour accéder à cette instance unique.  Quand Utiliser: La classe ne doit avoir qu'une seule instance.  Exemple: Cas d'une ressource système,  Résultat: Isole l'unicité d'une instance. 17
  • 19. Designs pattern structuraux Organisent les interfaces/classes entre elles 19
  • 20. 7 designs pattern structuraux  Adaptateur: Convertir l'interface d'une classe dans une autre interface comprise par la partie cliente  Pont: Découpler l'abstraction d'un concept de son implémentation  Composite: Permettre à la partie cliente de manipuler un objet unique et un objet composé de la même manière  Décorateur: Ajouter dynamiquement des responsabilités à un objet  Façade: Fournir une interface unique en remplacement d'un ensemble d'interfaces d'un sous-système  Poids-Mouche: Utiliser le partage pour gérer efficacement un grand nombre d'objets de faible granularité  Proxy: Fournir un intermédiaire entre la partie cliente et un objet pour contrôler les accès à ce dernier 20
  • 21. Adaptateur (Adapter ou Wrapper)  Objectifs: Convertir l'interface d'une classe dans une autre interface comprise par la partie cliente.  Quand Utiliser: Le système doit intégrer un sous- système existant. Ce sous-système a une interface non standard par rapport au système.  Exemple: Cas d’un driver bas niveau fournit par le fabricant ne correspondant pas à l'interface utilisée par le système pour d'autres drivers.  Résultat: Isole l'adaptation d'un sous-système. 21
  • 22. Adaptateur (Adapter ou Wrapper) 22
  • 23. Pont (Bridge ou Handle/Body)  Objectifs: Découpler l'abstraction d'un concept de son implémentation.  Quand Utiliser: Le système comporte une couche bas niveau réalisant l'implémentation et une couche haut niveau réalisant l'abstraction. Il est nécessaire que chaque couche soit indépendante.  Exemple: Système d'édition de documents d'une application. Pour l'implémentation, l'édition aboutit à une sortie imprimante, une image sur disque, un document PDF, etc. Pour l'abstraction, il s'agit d'édition de factures, de rapports de stock ou de courriers divers.  Résultat: Isole le lien entre une couche de haut niveau et celle de bas niveau. 23
  • 24. Pont (Bridge ou Handle/Body) 24
  • 25. Composite (Composite)  Objectifs: Permettre à la partie cliente de manipuler un objet unique et un objet composé de la même manière.  Quand Utiliser: Le système comporte une hiérarchie avec un nombre de niveaux non déterminé. Il faut pouvoir considérer un groupe d'éléments comme un élément unique.  Exemple: Logiciel de DAO, plusieurs éléments graphiques peuvent être regroupés en un nouvel élément graphique.  Résultat: Isole l'appartenance à un agrégat. 25
  • 27. Décorateur (Decorator ou Wrapper)  Objectifs: Ajouter dynamiquement des responsabilités à un objet.  Quand Utiliser: Il est nécessaire de pouvoir étendre les responsabilités d'une classe sans avoir recours au sous- classage.  Exemple: Cas d'une classe gérant des d'entrées/sorties à laquelle on souhaite ajouter un buffer et des traces de log.  Résultat: Isole les responsabilités d'un objet. 27
  • 29. Façade (Facade)  Objectifs: Fournir une interface unique en remplacement d'un ensemble d'interfaces d'un sous-système.  Quand Utiliser: Le système comporte un sous-système complexe avec plusieurs interfaces, certaines présentant des opérations pas utiles au reste du système.  Exemple: Cas d'un sous-système communiquant avec des outils de mesure.  Résultat: Isole les fonctionnalités d'un sous-système utiles à la partie cliente. 29
  • 31. Poids-Mouche (Flyweight)  Objectifs: Utiliser le partage pour gérer efficacement un grand nombre d'objets de faible granularité.  Quand Utiliser: Un système utilise un grand nombre d' instances. Chacune de ces instances a des attributs propre au contexte et propre à l'objet.  Exemple: Cas caractéristiques des traits dans un logiciel de DAO. Les caractéristiques d'épaisseur, d'ombre sont intrinsèques, et les coordonnées sont extrinsèques.  Résultat: Isole les propriétés partageables des objets. 31
  • 33. Proxy (Proxy ou Surrogate)  Objectifs: Fournir un intermédiaire entre la partie cliente et un objet pour contrôler les accès à ce dernier.  Quand Utiliser: Les opérations d'un objet sont coûteuses en temps ou sont soumises à une gestion de droits d'accès.  Exemple: Cela peut être un système de chargement d'un document (gestion droits d’accès).  Résultat: Isole le comportement lors de l'accès à un objet. 33
  • 34. Proxy (Proxy ou Surrogate) 34
  • 35. Design patterns Comportementaux Définissent la communication entre les classes et leurs responsabilités 35
  • 36. 11 design patterns Comportementaux (1/2)  Chaîne de responsabilité: Eviter le couplage entre l' émetteur d'une requête et son récepteur en donnant à plus d'un objet une chance de traiter la requête  Commande : Paramétrer facilement des requêtes diverses.  Interpréteur : Définir une représentation de la grammaire d'un langage.  Itérateur : Fournir un moyen de parcourir séquentiellement les éléments d'un objet composé.  Médiateur : Gérer la transmission d'informations entre des objets interagissant entre eux  Memento : Sauvegarder l' état interne d'un objet en respectant l' encapsulation, afin de le restaurer plus tard. 36
  • 37. 11 design patterns Comportementaux (2/2)  Observateur : Prévenir des objets observateurs, enregistrés auprès d'un objet observé, d'un événement  Etat : Changer le comportement d'un objet selon son état interne.  Stratégie : Définir une famille d' algorithmes interchangeables, indépendamment de la partie cliente.  Patron de méthode : Définir le squelette d'un algorithme en déléguant certaines étapes à des sous- classes.  Visiteur : Séparer un algorithme d'une structure de données. 37
  • 38. Chaîne de responsabilité (Chain of responsibility)  Objectifs: Eviter le couplage entre l' émetteur d'une requête et son récepteur en donnant à plus d'un objet une chance de traiter la requête.  Quand Utiliser: Le système doit gérer un requête. La requête implique plusieurs objets pour la traiter.  Exemple: Cas d'un système complexe d'habilitations possédant plusieurs critères afin d'autoriser l'accès. Ces critères peuvent varier en fonction de la configuration.  Résultat: Isole les différentes parties d'un traitement. 38
  • 39. Chaîne de responsabilité (Chain of responsibility) 39
  • 40. Commande (Command, Action ou Transaction)  Objectifs:  Encapsuler une requête sous la forme d' objet.  Paramétrer facilement des requêtes diverses.  Permettre des opérations réversibles  Quand Utiliser: Le système doit traiter des requêtes, pouvant provenir de plusieurs émetteurs et pouvant être annulées.  Exemple: cas d'une IHM avec des boutons de commande, des raccourcis clavier et des choix de menu aboutissant à la même requête.  Résultat: Isole une requête. 40
  • 41. Commande (Command, Action ou Transaction) 41
  • 42. Interpréteur (Interpreter)  Objectifs:  Définir une représentation de la grammaire d'un langage.  Utiliser cette représentation pour interpréter les éléments de ce langage.  Quand Utiliser: Le système doit interpréter un langage.  Exemple: Cas d'un logiciel embarqué dont la configuration des écrans serait stockée dans des fichiers XML.  Résultat: Isole les éléments d'un langage. 42
  • 44. Itérateur (Iterator ou Cursor)  Objectifs: Fournir un moyen de parcourir séquentiellement les éléments d'un objet composé.  Quand Utiliser: Le système doit parcourir les éléments d'un objet complexe,  Exemple: Cas des classes représentant des listes et des ensembles en Java.  Résultat: Isole le parcours d'un agrégat. 44
  • 46. Médiateur (Mediator)  Objectifs: Gérer la transmission d'informations entre des objets interagissant entre eux.  Quand Utiliser: Différents objets ont des interactions. Un événement sur l'un provoque une (ou des) action(s) sur un (ou d‘)autre(s) objets,  Exemple: Cas des éléments d'IHM. Si une case est cochée, certains éléments deviennent accessibles.  Résultat: Isole la communication entre des objets. 46
  • 48. Memento (Memento)  Objectifs: Sauvegarder l' état interne d'un objet en respectant l' encapsulation, afin de le restaurer plus tard.  Quand Utiliser: Un système doit conserver et restaurer l'état d'un objet. L'état interne de l'objet à conserver n'est pas visible par les autres objets.  Exemple: Cas d’un éditeur de document disposant d'une fonction d'annulation  Résultat: Isole la conservation de l'état d'un objet. 48
  • 49. Memento (Memento) La partie cliente demande au Createur de stocker son état dans un Memento. Elle demande au Gardien de conserver ce Memento. Elle peut alors demander au Gardien de lui fournir un des Memento conservés, ou bien elle demande au Createur de restituer 49 son état depuis le Memento.
  • 50. Observateur (Observer)  Objectifs: Prévenir des objets observateurs, enregistrés auprès d'un objet observé, d'un événement.  Quand Utiliser: Un objet doit connaitre les changements d' état d'un autre objet. L'objet doit être informé immédiatement.  Exemple: Cas d'un tableau affichant des statistiques. Si une nouvelle donnée est entrée, les statistiques sont recalculées  Résultat: Isole un algorithme traitant un événement. 50
  • 51. Observateur (Observer) La partie cliente indique à l'objet Observe les objets Observateur qu'il avertira. 51
  • 52. Etat (State)  Objectifs: Changer le comportement d'un objet selon son état interne.  Quand Utiliser: Un objet a un fonctionnement différent selon son état interne.  Exemple: Cas d’un document informatique. Il a comme fonctions ouvrir, modifier. Le comportement de ces méthodes change selon l'état du document  Résultat: Isole les algorithmes propres à chaque état d'un objet. 52
  • 54. Stratégie (Strategy)  Objectifs: Définir une famille d' algorithmes interchangeables, indépendamment de la partie cliente.  Quand Utiliser: Un objet doit pouvoir faire varier une partie de son algorithme.  Exemple: Cas d’un Cela peut être une liste triée. Le tri peut être alphabétique, inverse, les majuscules avant les miniscules, …  Résultat: Isole les algorithmes appartenant à une même famille d'algorithmes. 54
  • 55. Stratégie (Strategy) La partie cliente configure un objet ClasseUtilisantStrategie avec un objet Strategie 55 et appelle la méthode de ClasseUtilisantStrategie qui utilise la stratégie.
  • 56. Patron de méthode (Template method)  Objectifs: Définir le squelette d'un algorithme en déléguant certaines étapes à des sous-classes.  Quand Utiliser: Une classe possède un fonctionnement global. Mais les détails de son algorithme doivent être spécifiques à ses sous-classes.  Exemple: Cas d'un document informatique qui peut être sauvegardé. Selon le type de document, il ne sera pas sauvegardé de la même manière, …  Résultat: Isole les parties variables d'un algorithme. 56
  • 57. Patron de méthode (Template method) La partie cliente appelle la méthode de AbstractClasse qui définit l'algorithme 57
  • 58. Visiteur (Visitor)  Objectifs: Séparer un algorithme d'une structure de données.  Quand Utiliser: Il est nécessaire de réaliser des opérations, sur les éléments d'un objet structuré, qui varient en fonction de la nature de chaque élément et peuvent être de plusieurs types.  Exemple: Cas d'un logiciel d'images de synthèse. L'image composée de plusieurs objets : sphère, polygone, etc... Sur chaque élément, il faut effectuer plusieurs opérations pour le rendu : ajout des couleurs, effet d'éclairage, …  Résultat: Isole les algorithmes appliquées sur des structures de données 58
  • 59. Visiteur (Visitor) La partie cliente appelle les méthodes de réception d'un Visiteur des Element. 59
  • 60. Références  http://rpouiller.developpez.com/tutoriel/java/design- patterns-gang-of-four/  Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (trad. Jean-Marie Lasvergères), Design Patterns - Catalogue de modèles de conceptions réutilisables 60