Les Design Patterns (ou Patron de Conception)

Transcription

1 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 1/35 12/12/ :33:44 Chapitre 04 Les Design Patterns (ou Patron de Conception) L'objectif de ce chapitre est d'introduire le concept des design patterns en parcourant rapidement certains. 1. INTRODUCTION 3 2. DEFINITIONS LE «PATRON» LE «CANEVAS» 5 3. LES MODELES DE CREATION FABRIQUE DE CREATION NOM ET ROLE DESCRIPTION DU PROBLEME A RESOUDRE DESCRIPTION DE LA SOLUTION EXEMPLE DE FACTORY LE SINGLETON NOM ET ROLE DESCRIPTION DU PROBLEME A RESOUDRE DESCRIPTION DE LA SOLUTION EXEMPLE DE SINGLETON LE BUILDER NOM ET ROLE DESCRIPTION DU PROBLEME A RESOUDRE DESCRIPTION DE LA SOLUTION EXEMPLE DE BUILDER LES MODELES DE STRUCTURE L'ADAPTATEUR NOM ET ROLE COLLABORATION CONVERSION DEFAUT LE PROXY NOM ET ROLE DESCRIPTION DU PROBLEME A RESOUDRE DESCRIPTION DE LA SOLUTION EXEMPLE DE PROXY 26 page 1/35

2 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 2/35 12/12/ :33:44 5. LES MODELES DE COMPORTEMENT ITERATOR BEAN MVC NOM ET ROLE DESCRIPTION DU PROBLEME A RESOUDRE EXEMPLE DE MVC : L'EXEMPLE CONCLUSION 35 page 2/35

3 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 3/35 12/12/ :33:44 1. Introduction AD 2. Définitions 2.1. Le «Patron» Les "patrons de conception" ou Design Patterns" sont des modèles standard et réutilisables de conception d'une la solution à la problématique de la réalisation d'une partie d'un logiciel informatique. Ensemble de règle (définition d éléments, principes de composition, règles d usage) permettant de répondre à une classe de besoins spécifiques dans un environnement donné. Dans une démarche de conception, quand on crée des programmes informatiques, on retrouve souvent des démarches identiques qui se traduisent par des assemblages de composants informatiques semblables. Certains de ces assemblages ou architecture semblables ont été modélisés et forment un ensemble de modèles qu'il faut apprendre à connaître car pourquoi réinventer la roue à chaque fois. De la même manière que nous avons des algorithmes types (modèle de code ou méthode générique) qui reviennent souvent, pour modéliser les traitements informatiques, nous avons les design patterns pour les assemblages des classes d'objet. Ainsi, là où un algorithme s'attache à décrire d'une manière précise comment résoudre un problème particulier, les patrons de conception décrivent des procédés de conception généraux et permettent en conséquence de mieux capitaliser l'expérience appliquée à la conception logicielle. Il a donc également une grande influence sur l'architecture logicielle d'un système. L'objectif visé est la réutilisation des moyens de conception logicielle afin de réduire les coûts d'ingénierie et de garantir un bon niveau de qualité. Propriétés d un PATRON : Un patron est élaboré à partir de l expérience acquise au cours de la résolution d une classe de problèmes apparentés. Il capture des éléments de solution communs Un patron définit des principes de conception, non des implémentations spécifiques de ces principes Un patron fournit une aide à la documentation, par ex. en définissant une terminologie, voire une description formelle ( langage de patrons») Un design pattern est défini par : - un nom - une description du problème à résoudre - une description de la solution : le patron de conception (schémas UML par ex) Certains patrons sont un assemblage d'autres patrons de plus bas niveau. Cela signifie bien que ces patrons constituent bien une boite à outils de conception. Par exemple : le design pattern MVC (Model Vue Controller) utilise les design patterns Observateur, Stratégie et Composite. Les patrons de conception les plus connus sont au nombre de 23. page 3/35

4 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 4/35 12/12/ :33:44 On distingue 3 familles de patrons de conception selon leur utilisation : de construction (ou création) : ils définissent comment faire l'instanciation et la configuration des classes et des objets. structuraux : ils définissent comment organiser les classes d'un programme dans une structure plus large (séparant l'interface de l'implémentation). comportementaux : ils définissent comment organiser les objets pour que ceuxci collaborent (distribution des responsabilités) et expliquent le fonctionnement des algorithmes impliqués. Création : - Moniteur Builder - Fabrique Factory - Prototype Prototype - Singleton Singleton Structure : - Adaptateur Adapter - Pont Bridge - Objet composite Composite - Décorateur Decorator - Façade Facade - Poids-plume Flyweight - Proxy Proxy Comportement : - Chaîne de responsabilité Chain of responsibility - Commande Command - Interpréteur Interpreteur - Itérateur Iterator - Médiateur Mediator - Mémento Memento - Observateur Observer - Etat State - Stratégie Strategy - Patron de méthode Template Method - Visiteur Visitor - Fonction de rappel Callback Autres : - Responsabilités (Patron GRASP) - Expert (Patron GRASP) - Créateur (Patron GRASP) - Faible couplage (Patron GRASP) - Forte cohésion (Patron GRASP) - Contrôleur (Patron GRASP) - Polymorphisme (Patron GRASP) - Indirection (Patron GRASP) - Fabrication pure (Patron GRASP) - Kit - Modèle-Vue-Contrôleur - Inversion de contrôle - Injection de dépendances page 4/35

5 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 5/35 12/12/ :33: Le «Canevas» Un canevas est un squelette de code représentant l implémentation de un ou plusieurs patrons. Dans les langages objets : Un canevas est un «squelelte» de plusieurs classes qui peuvent être réalisées et adaptées pour une famille d applications donnée Il est un ensemble de classes, souvent abstraites, devant être adaptées par exemple par surcharge. Généralement ; on accompagne les canevas d un ensemble de règles d usage décrites dans une documentation. En conclusion : les patrons et canevas sont deux techniques de réutilisation les patrons réutilisent un schéma de conception ; les canevas réutilisent du code. Notre objectif n'est pas de décrire exhaustivement tous ces patrons mais d'explorer les plus courants. Et à travers ces explorations d'apprendre à lire et manipuler les design patterns mais aussi à assimiler les concepts d'architecture des langages objets. Il est entendu qu'un minimum de connaissance en UML est nécessaire pour lire les diagrammes de description des design patterns. Pour quelqu'un qui découvre la programmation objet, il pourrait paraître inutile d'utiliser une telle démarche dans la réalisation de ces premiers programmes. C'est vrai que dans un premier temps, on préfère se consacrer aux bases de la programmation objet avant de parler réutilisation, conception, architecture ou performance. Très vite, le programmeur est un concepteur et donc très vite, il est confronté à faire des choix de conception pour lesquels les design patterns sont des éléments de sa conception. Il ne faut donc pas négliger la connaissance de ces design patterns. C'est pourquoi, dans le cadre de la présente formation, nous allons aborder certains design patterns parmi les plus connus. 3. Les modèles de création Ce qui guide ce type de modèle est de pouvoir faire la création d'objet (instanciation) sans être nécessairement impacté par l'évolution de la classe et de ses constructeurs Fabrique de création Nom et rôle Factory ou Usine de fabrication Une telle usine fabrique des objets, à la demande, au sens des LOO. page 5/35

6 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 6/35 12/12/ :33: Description du problème à résoudre Dans un système d'information (SI), il existe des objets particuliers qui sont des données récurrentes devant être créées de nombreuses fois durant le fonctionnement du programme, et ceci à de multiples endroits du programme. Ces données sont des objets métiers (dans une architecture Client-Serveur, on parle de Business Object). Ces objets sont souvent stockés ou persistants dans une base de données). Le factory assure alors les propriétés liées à la base de données. Il y a donc un besoin de centraliser cette création d'objet mais aussi d'être le moins impacté possible si la classe de ces objets évolue Description de la solution La solution est de créer une classe qui va servir de point central de création de l'objet. a. Variante de base Une usine (ou factory) est une classe qui contient des méthodes de création d'objet qui reposent sur les principes suivants : 1/ Chaque méthode de création retourne une interface donnée (vision abstraite) 2/ Chaque méthode de création exploite un constructeur d'une classe (vision concrète) 3/ Cette classe concrète implémente les méthodes de l'interface L'adhérence de l'évolution d'un factory est donc restreint aux interfaces. Le client fait une demande de création d'un objet à un Factory. Le factory retourne un objet qui est vu par le client sous l'aspect d'une interface Product. Cet objet est une instance de la classe ConcreteProduct qui implémente d'interface Product. page 6/35

7 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 7/35 12/12/ :33:44 b. Plusieurs type de produits Il existe des Factory qui créent des objets concrets de différentes natures en fonction des requêtes différentes du client. Dans ce cas le factory crée des objets concrets de différentes natures dont les classes d'appartenance héritent d'une classe abstraite et implémentent la même interface. Ceci pour que le client perçoit chacun des produits d une manière unique. Le factory abstrait ainsi les choix de conception et d implémentation des objets créés. La classe abstraite est utilisée pour créer une collection polymorphe dans le factory. Au-delà de la création, le factory définit des méthodes de gestion des produits : recherche, accès, indexation, comparaison, tri, modifications, Exemple de Factory import java.util.*; Programme principal du test du factory public class MainFactory public static void main(string[] args) Creation du factory CarteGriseFactory usine = new CarteGriseFactory(); Exemple de creation d'un objet du factory CarteGrise cg1 = usine.getinstance("lafont", "PIERRE", "AM 613 HC"); page 7/35

8 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 8/35 12/12/ :33:44 System.out.println(cg1.toString()); Deux autres créations : usine.getinstance("dupont", "PAUL", "SM 312 HC"); usine.getinstance("garric", "JEAN", "AM 234 AZ"); Recherche dans le factory while (true) System.out.print("Recherche : "); String str = Terminal.lireString(); ArrayList<CarteGrise> lcg = usine.search(str); for(cartegrise cg : lcg) System.out.println(" "); System.out.println(cg.toString()); import java.util.*; L'interface d'une carte grise public interface CarteGrise public String getnom(); public String getprenom(); public String getnumeroplaque(); public Calendar get1eremiseencirculation(); public String getreference(); public String getadresse(); public void setadresse(string adresse); import java.util.*; /** * Classe de définition du factory de carte grise */ public class CarteGriseFactory stockage des objets de l'usine Chaque carte-grise est stocké dans une table de hashing dont la clef est une référence déterminée par la classe CarteGriseImpl. private Hashtable<String,CarteGriseImpl> cartegrises; Constructeur de création de l'usine public CarteGriseFactory() page 8/35

9 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 9/35 12/12/ :33:44 cartegrises = new Hashtable<String,CarteGriseImpl>(); Creation d'une carte grise en fonction de certaines données. La date de 1ère mise en circulation est créée automatiquement. Ainsi que le numéro de référence interne. public CarteGrise getinstance(string nom, String prenom, String numeroplaque) CarteGriseImpl cg; cg = new CarteGriseImpl(nom,prenom,numeroPlaque); cartegrises.put(cg.getreference(),cg); return(cg); Recherche le morceau de chaine dans chacun des attributs de la carte grise public ArrayList<CarteGrise> search(string critere) ArrayList<CarteGrise> lcg = new ArrayList<CarteGrise>(); for(cartegriseimpl cg : cartegrises.values()) String str = cg.tostring(); if (str.tolowercase().indexof(critere.tolowercase())!=-1) lcg.add(cg); return lcg; import java.util.*; La classe concrete d'implémentation d'une carte grise public class CarteGriseImpl implements CarteGrise private static long compteur=0; utilisé pour la référenc eunique d'une cg private String nom; private String prenom; private String adresse; private String numeroplaque; private Calendar date1eremiseencirculation; private String reference; Constructeur d'une carte grise public CarteGriseImpl(String nom, String prenom, String numeroplaque) this.nom = nom; page 9/35

10 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 10/35 12/12/ :33:44 this.prenom = prenom; this.numeroplaque = numeroplaque; this.date1eremiseencirculation = Calendar.getInstance(); Remarque au passage : Calendar, c'est à la fois un Singleton et un factory compteur++; this.reference = String.format("%4d/%06d", this.date1eremiseencirculation.get(calendar.year), compteur); Carte grise sous la forme d'une chaine de caractere public String tostring() return(this.nom+"\n"+ this.prenom+"\n"+ this.adresse+"\n"+ this.numeroplaque+"\n"+ this.date1eremiseencirculation.gettime()+"\n"+ this.reference); L'implémentation des methodes de l'interface public String getnom()return this.nom; public String getprenom()return this.prenom; public String getnumeroplaque()return this.numeroplaque; public Calendar get1eremiseencirculation()return this.date1eremiseencirculation; public String getreference()return this.reference; public String getadresse()return this.adresse; public void setadresse(string adresse)this.adresse=adresse; page 10/35

11 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 11/35 12/12/ :33: Le singleton Nom et rôle Singleton Le rôle de ce design pattern est la création d'une instance d'objet unique dans la JVM Description du problème à résoudre L'objectif est de limiter le nombre d'instance d'un objet qui dans le cas d'un singleton est toujours égal à 1. Un singleton est donc un factory à instanciation unique Description de la solution Il existe deux solutions possibles : - soit l'instance unique est créée lors de la définition de la classe (CAS 1) - soit l'instance unique est créée à la demande lors de la 1ère utilisation (CAS 2) On fait comme pour le factory précédent en créant une méthode getinstance qui va retourner la création d'un objet mais on fera le nécessaire pour que si on appelle une seconde fois la méthode getinstance, au lieu de créer un nouvel objet, la méthode retournera l'objet précédemment créé Exemple de Singleton CAS1 : import java.util.*; page 11/35

12 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 12/35 12/12/ :33:44 /** * Classe de définition du factory de carte grise */ public class CarteGriseFactory Le singleton : l'usine unique de carte grise static private CarteGriseFactory usine = new CarteGriseFactory(); stockage des objets de l'usine Chaque carte-grise est stocké dans une table de hashing dont la clef est une référence déterminée par la classe CarteGriseImpl. private Hashtable<String,CarteGriseImpl> cartegrises;... Le constructeur est privé private CarteGriseFactory() cartegrises = new Hashtable<String,CarteGriseImpl>(); Methode qui retourne le singleton static public CarteGriseFactory getusine() return usine; import java.util.*; Programme principal du test du factory public class MainFactory public static void main(string[] args) Creation du factory CarteGriseFactory usine = CarteGriseFactory.getUsine(); Exemple de creation d'un objet du factory CarteGrise cg1 = usine.getinstance("lafont", "PIERRE", "AM 613 HC"); System.out.println(cg1.toString()); Deux autres créations : usine.getinstance("dupont", "PAUL", "SM 312 HC"); usine.getinstance("garric", "JEAN", page 12/35

13 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 13/35 12/12/ :33:44 "AM 234 AZ"); Pour démontrer que c'est bien un singleton CarteGriseFactory usine2 = CarteGriseFactory.getUsine(); Recherche dans le factory while (true) System.out.print("Recherche : "); String str = Terminal.lireString(); ArrayList<CarteGrise> lcg = usine2.search(str); for(cartegrise cg : lcg) System.out.println(" "); System.out.println(cg.toString()); CAS2 : import java.util.*; /** * Classe de définition du factory de carte grise */ public class CarteGriseFactory Le singleton : l'usine unique de carte grise static private CarteGriseFactory usine = null; stockage des objets de l'usine Chaque carte-grise est stocké dans une table de hashing dont la clef est une référence déterminée par la classe CarteGriseImpl. private Hashtable<String,CarteGriseImpl> cartegrises; Nom de l'usine private String nomusine; Le constructeur est privé private CarteGriseFactory(String nomusine) cartegrises = new Hashtable<String,CarteGriseImpl>(); this.nomusine = nomusine; Methode qui retourne le singleton static public CarteGriseFactory getusine(string nomusine) if (usine==null) page 13/35

14 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 14/35 12/12/ :33:44 usine = new CarteGriseFactory(nomUsine); else usine.setnomusine(nomusine);... return usine; import java.util.*; Programme principal du test du factory public class MainFactory public static void main(string[] args) Creation du factory CarteGriseFactory usine = CarteGriseFactory.getUsine("USINE 1"); Exemple de creation d'un objet du factory CarteGrise cg1 = usine.getinstance("lafont", "PIERRE", "AM 613 HC"); System.out.println(cg1.toString()); Deux autres créations : usine.getinstance("dupont", "PAUL", "SM 312 HC"); usine.getinstance("garric", "JEAN", "AM 234 AZ"); Pour démontrer que c'est bien un singleton CarteGriseFactory usine2 = CarteGriseFactory.getUsine("USINE 2"); + " : "); Recherche dans le factory while (true) System.out.print("Recherche dans "+ usine2.getnomusine() String str = Terminal.lireString(); ArrayList<CarteGrise> lcg = usine2.search(str); for(cartegrise cg : lcg) System.out.println(" "); System.out.println(cg.toString()); page 14/35

15 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 15/35 12/12/ :33: Le builder Nom et rôle Builder ou Monteur. Le rôle de ce design pattern est la construction d'un objet par assemblage. On "monte" l'objet Description du problème à résoudre L'objectif est d'éviter la définition de nombreux constructeurs qui ont de plus en plus de paramètre. Le problème d'une Fabrique de création, c'est qu'elle permet de définir comment un objet va être construit, certes, il est toujours possible de passer x paramètres dans la méthode de création d'une fabrique mais cela s'avère souvent très réducteurs voir délicat pour la maintenance. On fait le constat que la plupart des objets dits "complexes" sont composés d'autres objets. Cela veut dire que la définition de l'objet cible est une agrégation d'autres instances. Si en plus, il est possible d'avoir une valeur par défaut (null par ex) pour chacun de ces éléments, alors on peut mettre en place un "Builder" Description de la solution Le "Builder" est une classe qui contient : - une méthode permettant d'initialiser l'objet à monter (à ne pas confondre avec une instanciation). Cet objet est rémanent dans le builder. - autant de méthode (add) que de composants à assembler page 15/35

16 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 16/35 12/12/ :33: Exemple de builder Programme principal du test du builder public class MainBuilder public static void main(string[] args) throws Exception Creation du builder CarteGriseBuilder builder = new CarteGriseBuilder(); Construction d'une carte grise CarteGriseImpl cg1 = new CarteGriseImpl(); builder.initcartegrise(cg1); builder.addindividu("dupont", "PAUL"); System.out.println(" "); System.out.println(cg1); builder.addimmatriculation("sm 312 HC"); System.out.println(" "); System.out.println(cg1); builder.addvehicule("skoda","rommster","123df56c"); System.out.println(" "); System.out.println(cg1); Construction d'une autre carte grise CarteGriseImpl cg2 = new CarteGriseImpl(); builder.initcartegrise(cg2); builder.addindividu("durand", "PIERRE", "22 rue du point TOULOUSE 31100"); System.out.println(" "); System.out.println(cg2); builder.addimmatriculation("ze 322 HD"); System.out.println(" "); System.out.println(cg2); builder.addvehicule("renault","21 Nevada","12SD3DF56C"); System.out.println(" "); System.out.println(cg2); public class CarteGriseBuilder private CarteGriseImpl cartegrise; public CarteGriseBuilder() page 16/35

17 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 17/35 12/12/ :33:44 cartegrise=null; public void initcartegrise(cartegriseimpl cg) cartegrise=cg; public void addindividu(string nom,string prenom,string adresse) cartegrise.setindividu(new Individu(nom,prenom,adresse)); public void addindividu(string nom,string prenom) cartegrise.setindividu(new Individu(nom,prenom,null)); public void addindividu(individu ind) addindividu(ind.getnom(),ind.getprenom(),ind.getadresse()); public void addimmatriculation(string numeroplaque) throws Exception cartegrise.setimmatriculation(new Immatriculation(numeroPlaque)); cartegrise.initreference(); public void addvehicule(string marque,string type,string serie) cartegrise.setvehicule(new Vehicule(marque,type,serie)); La classe concrete d'implémentation d'une carte grise public class CarteGriseImpl implements CarteGrise private static long compteur=0; utilisé pour la référence unique d'une cg private Individu individu; private Immatriculation immatriculation; private Vehicule vehicule; private String reference; Constructeur d'une carte grise public CarteGriseImpl() this.individu = null; this.immatriculation = null; this.vehicule = null; this.reference = null; Initilaisation de la référence public void initreference() throws Exception page 17/35

18 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 18/35 12/12/ :33:44 if (this.immatriculation==null) throw new Exception("La Date de 1ere mise en circulation n'est pas définie"); compteur++; this.reference = String.format("%4d/%06d", this.immatriculation.getdate1eremiseencirculation().get(calendar.year), compteur); Carte grise sous la forme d'une chaine de caractere public String tostring() return(this.individu+"\n"+ this.immatriculation+"\n"+ this.reference+"\n"+ this.vehicule); Les getteurs/setteurs public void setindividu(individu individu)this.individu = individu; public void setimmatriculation(immatriculation immatriculation)this.immatriculation = immatriculation; public void setvehicule(vehicule vehicule)this.vehicule = vehicule; L'implémentation des methodes de l'interface public String getnom()return this.individu.getnom(); public String getprenom()return this.individu.getprenom(); public String getadresse()return this.individu.getadresse(); public void setadresse(string adresse)this.individu.setadresse(adresse); public String getnumeroplaque()return this.immatriculation.getnumeroplaque(); public Calendar get1eremiseencirculation()return this.immatriculation.getdate1eremiseencirculation(); public String getreference()return this.reference; public class Individu private String nom; private String prenom; private String adresse; public Individu(String nom,string prenom) this.nom=nom; this.prenom=prenom; public Individu(String nom,string prenom,string adresse) this.nom=nom; this.prenom=prenom; this.adresse = adresse; public String getnom()return this.nom; public String getprenom()return this.prenom; public String getadresse()return this.adresse; page 18/35

19 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 19/35 12/12/ :33:44 public void setadresse(string adresse)this.adresse=adresse; public String tostring() return(this.nom+"\n"+ this.prenom+"\n"+ this.adresse); public class Immatriculation private String numeroplaque; private Calendar date1eremiseencirculation; public Immatriculation(String numeroplaque) this.numeroplaque = numeroplaque; this.date1eremiseencirculation = Calendar.getInstance(); public String getnumeroplaque()return numeroplaque; public Calendar getdate1eremiseencirculation()return date1eremiseencirculation; public String tostring() return(this.numeroplaque+"\n"+ this.date1eremiseencirculation.gettime()); public class Vehicule private String marque; private String type; private String serie; public Vehicule(String marque, String type, String serie) this.marque = marque; this.type = type; this.serie = serie; public String getmarque()return marque; public String gettype()return type; public String getserie()return serie; public String tostring() return(this.marque+" "+this.type+" "+this.serie); page 19/35

20 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 20/35 12/12/ :33:44 4. Les modèles de structure L'usage commun des design patterns de structure est d'utiliser les propriétés des langages objets (héritage, interface, classe abstraite, ) pour regrouper les objets et leurs appliquer ou définir des traitements sans avoir besoin de le faire sur chacun d'eux. Par exemple, l'interface elle-même est un design patttern qui permet, de par son implémentation dans différentes classes, de créer des collections polymorphes et des traitements génériques. Ces modèles de structures permettent aussi de concevoir des interfaces complexes d'échange et de communication entre différents composants informatiques d'un SI. Par exemple, la séparation entre l'applicatif et son ihm via l'usage de l'interface et de proxy pour sa séparation dans une architecture client-serveur L'adaptateur Nom et rôle Adaptateur ou Adapter. Le rôle général d'un Adapter est de s'adapter à des interfaces et des classes qui utilisent ces interfaces, sans les faire évoluer (car cela pourrait être pénalisant ou tout simplement parce que l'on n'a pas le code source). Les différents rôles d'un adaptateur est de : - faire collaborer des classes entre elles alors qu'elles n'auraient pas pu le faire du fait d'interfaces incompatibles. - de convertir des objets en d'autres objets (adapter ses comportements) page 20/35

21 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 21/35 12/12/ :33:44 - de définir des comportements par défaut pour des méthodes d'une interface. Analysons chacun de ces 3 cas Collaboration a. Description du problème à résoudre On a des classes qui ne peuvent pas implémenter une interface utilisée dans un traitement générique alors que l'on veut que cette classe soit utilisée dans le traitement générique. b. Description de la solution On crée une classe intermédiaire, l'adaptateur, qui agrège l'objet incompatible et qui implémente l'interface dont le code exploite les méthodes de la classe incompatible. c. Exemple de Adapter public class Collaboration public static void main(string[] args) on crée le chargeur Chargeur chargeur = new Chargeur(); /******************** Portable Compatible *******************/ PortableCompatible portablecompatible = new PortableCompatible(); chargeur.brancherportable(portablecompatible); System.out.println (""); /******************** Portable SonneEricSonne ***************/ on crée le portable et son adaptateur PortableSonneEricSonne portablesonne = new PortableSonneEricSonne(20); AdaptateurSonneEricSonne adaptateursonne = new AdaptateurSonneEricSonne(portableSonne); on donne le portable à charger mais en utilisant son adaptateur chargeur.brancherportable(adaptateursonne); System.out.println (""); /********************* Portable SamSaoule *******************/ on crée le portable et son adaptateur PortableSamSaoule portablesam = new PortableSamSaoule(); AdaptateurSamSaoule adaptateursam = new AdaptateurSamSaoule(portableSam); on donne le portable à charger mais en utilisant son adaptateur chargeur.brancherportable(adaptateursam); interface IChargeable public void recharger(int voltage); page 21/35

22 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 22/35 12/12/ :33:44 class Chargeur le voltage en sortie du chargeur private int voltage = 10; branchement d'un portable pour le charger public void brancherportable(ichargeable portable) System.out.println("branchement d'un portable"); portable.recharger(voltage); ================================================================ Un portable compatible avec l'interface IChargeable class PortableCompatible implements IChargeable public void recharger(int volts) System.out.println ("Portable Compatible en charge"); System.out.println ("voltage: " + volts); Un portable non compatible avec l'interface et dont la charge n'est pas la meme pour chaque instance class PortableSonneEricSonne ne se recharge int volts; public PortableSonneEricSonne(int volts) this.volts=volts; public void ChargerBatteries() System.out.println ("Portable SonneEricSonne en charge"); System.out.println ("voltage: " + volts); Portable non compatible avec l'interface et dont la charge est 5 volts class PortableSamSaoule ne se recharge qu'avec du 5 volts public final int volts = 5; public void ChargerPortable() System.out.println ("Portable SamSaoule en charge"); System.out.println ("voltage: " + volts); page 22/35

23 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 23/35 12/12/ :33:44 ========================================================== Les adaptateurs class AdaptateurSonneEricSonne implements IChargeable référence sur le portable adapté private PortableSonneEricSonne telephone; public AdaptateurSonneEricSonne(PortableSonneEricSonne portable) this.telephone = portable; public void recharger(int volts) this.telephone.chargerbatteries(); class AdaptateurSamSaoule implements IChargeable référence sur le portable adapté private PortableSamSaoule telephone; public AdaptateurSamSaoule(PortableSamSaoule portable) this.telephone = portable; le portable SamSaoule n'a besoin que de 5 volts public void recharger(int volts) this.telephone.chargerportable(); Exécution : branchement d'un portable Portable Compatible en charge voltage: 10 branchement d'un portable Portable SonneEricSonne en charge voltage: 20 branchement d'un portable Portable SamSaoule en charge voltage: Conversion a. Description du problème à résoudre On a besoin de manipuler des objets décrit par une interface sous la forme d'une autre interface. page 23/35

24 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 24/35 12/12/ :33:44 b. Description de la solution On crée un objet intermédiaire, appelé un adaptateur, qui va servir de "pont" entre la nouvelle interface et l'ancienne. Le pont implémente les méthodes de la nouvelle interface dont le code appelle les méthodes de la classe qui implémente l'ancienne interface. c. Exemple de Adapter public class Conversion public static void main(string[] args) Circle c = new CircleImpl(10,20,100); Point p = new CircleImplPointAdapter(c); System.out.println(p.getX()+" "+p.gety()); /** Interface de représentation d'un cercle */ interface Circle /** Retourne l'abscisse du centre du cercle */ public int getx(); /** Retourne l'ordonnée du centre du cercle */ public int gety(); /** Retourne le rayon du cercle */ public int getr(); /** Classe implémentant l'interface Circle */ class CircleImpl implements Circle int x,y; int r; public CircleImpl(int x,int y,int r) this.x=x; this.y=y; this.r=r; public int getx()return x; public int gety()return y; public int getr()return r; /** Interface de représentation d'un point */ interface Point /** Retourne l'abscisse du point */ public int getx(); /** Retourne l'ordonnée du point */ public int gety(); /** Adapteur pour transformer le circle en un point */ class CircleImplPointAdapter implements Point private Circle c; page 24/35

25 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 25/35 12/12/ :33:44 public CircleImplPointAdapter( Circle c ) this.c = c; public int getx() return c.getx(); public int gety() return c.gety(); Défaut a. Description du problème à résoudre Le problème se pose quand une interface est composée de nombreuses méthodes. Il faut alors que la classe qui implémente cette interface, implémente toutes les méthodes de l'interface. Si en plus, cette classe n'a pas besoin d'implémenter toutes les méthodes alors il est nécessaire de trouver une solution. b. Description de la solution La solution consiste à créer une classe appelé un Adapter. Cette classe implémente toutes les méthodes de l'interface avec du code par défaut. Ensuite, toute classe qui veut implémenter une partie de cette interface, au lieu d'implémenter l'interface, elle hérite de l'adapter. Cette classe hérite donc de toutes les méthodes par défaut, et il lui suffit de surcharger uniquement les méthodes dont elle a besoin. Le code qui utilisera cette classe via l'interface fera appel à toutes les méthodes et exécutera soit le code par défaut, soit le code surchargés. c. Exemple de Adapter Le meilleur exemple est celui de l'adapter de gestion des fenêtres IHM. public class IHM extends Thread Frame fen; boolean threadcontinue; public IHM() fen = new Frame(); fen.resize(300,200); Pour fermer l'ihm GrilleWindowAdapter a = new GrilleWindowAdapter(); fen.addwindowlistener((windowlistener)a); Affichage de la fenetre fen.show(); Demarrage du thread threadcontinue = true; start(); =============================================================== Classe interne pour gérer la fenetre du window manager =============================================================== page 25/35

26 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 26/35 12/12/ :33:44 class GrilleWindowAdapter extends WindowAdapter Fermeture de la fenetre public void windowclosing(windowevent e) Arret du thread threadcontinue = false; Destruction de la fenetre fen.dispose(); 4.2. Le Proxy Nom et rôle Proxy Assez proche de l'adapteur, le Proxy cherche à ajouter un niveau de redirection entre l'appel d'une méthode d'un objet et l'action associée Description du problème à résoudre Ce type de structure vise à pouvoir changer l'objet cible sans changer l'objet source (manipulé) Description de la solution A cet effet, on construit une nouvelle classe implémentant l'interface de l'objet à manipuler et déportant toutes les actions sur un autre objet implémentant la même interface. Les Proxy sont très utilisés pour la gestion d'objets distribués (protocole RMI en Java par exemple). L'idée étant de construire des Proxy capable de communiquer avec des objets distants (usage de la sérialisation en Java) sans que l'exploitant fasse de différences entre un accès local ou un accès distant Exemple de Proxy Séparation de l'applicatif et de l'ihm public class ExempleProxy public static void main(string[] args) Applicatif appimp = new ApplicatifImp(); ApplicatifProxy appproxy = new ApplicatifProxy(appImp); Exemple d'utilisation du Proxy Separation de l'ihm et de son applicatif Ihm ihm = new Ihm(appProxy); ihm.exemple(); class Ihm page 26/35

27 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 27/35 12/12/ :33:44 private Applicatif app; public Ihm(Applicatif app) this.app = app; public void exemple() int x = app.getx(); int y = app.gety(); app.setx(100); app.traitement(); interface Applicatif public int getx(); public int gety(); public void setx(int x); public void sety(int y); public void traitement(); class ApplicatifImp implements Applicatif private int x; private int y; public ApplicatifImp() x=10; y=20; public int getx()return x; public int gety()return y; public void setx(int x)this.x=x; public void sety(int y)this.y=y; public void traitement() System.out.println("Execution de traitement"); class ApplicatifProxy implements Applicatif private Applicatif app; public ApplicatifProxy(Applicatif app) this.app=app; public int getx() System.out.println("Appel a getx"); return app.getx(); page 27/35

28 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 28/35 12/12/ :33:44 public int gety() System.out.println("Appel a gety"); return app.gety(); public void setx(int x) System.out.println("Appel a setx"); app.setx(x); public void sety(int y) System.out.println("Appel a sety"); app.sety(y); public void traitement() System.out.println("Appel a traitement"); app.traitement(); Execution : java Proxy Appel a getx Appel a gety Appel a setx Appel a traitement Execution de traitement page 28/35

29 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 29/35 12/12/ :33:44 Pour mieux illustrer, l'usage de ce design pattern, on peut aller voir l'atelier 16 du cours NFP214 : Cet atelier montre la séparation de l'applicatif et de son Ihm par une interface qui permet de réaliser une architecture client/serveur basé sur le principe du Proxy avec deux solutions d'implémentation du proxy : une en RMI et une autre en http. 5. Les modèles de comportement Les modèles de comportement sont : - des modèles d'interfaces dont les méthodes virtuelles sous-entendent un comportement globale attendu par l'utilisateur et celui qui doit implémenter les méthodes. Ceci permet de mettre en commun des descriptions de comportements implémentés différemment dans différentes classes mais vu pour l'utilisateur de la même façon (exemple les interfaces des collections List, Iterator, - des architectures de classes abstraites dont l'architecture peut être modélisée et donc réutilisable dans des besoins et conceptions similaire (très proche de Best Pratices). Exemple : gestion d'un moteur de production et de consommation d'évènement en "Push" et "Pull" Autre exemple : le modèle MVC 5.1. Iterator L'interface Iterator est une interface dont les méthodes ont pour objet de parcourir des collections d'objet quelque soit l'implémentation. Exemple : Ceci est un exemple d'une interface d'itération que nous pourrions imaginer afin de faire des itérations identiques dans nos différentes classes de notre projet. import java.util.*; public class MyIteratorExemple public static void main(string[] args) ListeLivre livres = new ListeLivre("Fantastiques"); livres.ajouterlivre("les dragons de l'aurore"); livres.ajouterlivre("les rivières de sang"); livres.ajouterlivre("les cloches d'argent"); livres.init(); Livre l=(livre)(livres.next()); while (l!=null) System.out.println(l.getTitre()); l=(livre)(livres.next()); interface MyIterator Initialisation public void init(); Retourne le prochain élément sinon null public Object next(); page 29/35

30 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 30/35 12/12/ :33:44 class ListeLivre implements MyIterator String nomtheme; ArrayList<Livre> elements; int courantiterator; public ListeLivre(String nomtheme) this.nomtheme = nomtheme; elements = new ArrayList<Livre>(); public void ajouterlivre(string titre) this.elements.add(new Livre(titre)); public void init() courantiterator=0; public Object next() Livre l =null; try l = elements.get(courantiterator); catch(indexoutofboundsexception ex) return null; courantiterator++; return((object)l); class Livre private String titre; public Livre(String titre) this.titre=titre; public String gettitre() return titre; Execution : java MyIteratorExemple Les dragons de l'aurore Les rivières de sang Les cloches d'argent page 30/35

31 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 31/35 12/12/ :33: Bean Un Bean est un objet dont tous les attributs sont privés et dont tous les attributs ont un getteur et un setteur associés MVC Nom et rôle Modèle-Vue-Contrôleur Le design pattern Modèle-Vue-Contrôleur (MVC) est un pattern architectural qui sépare les données (le modèle), l'interface homme-machine (la vue) et la logique de contrôle (le contrôleur) Description du problème à résoudre Le problème est d'imaginer une architecture logicielle dans la réalisation d'application client/serveur (ex: Application Internet) qui assure une bonne maintenabilité de ses composants. Cela n'est pas nouveau, il faut séparer les systèmes d'information en au moins 2 couches: - la partie applicative qui réalise les traitements "métier" et gère les données - la partie IHM qui réalise l'interface avec les utilisateurs Ce qui est nouveau est l'apparition d'un nouveau composant : le contrôleur. Ce composant est issu de la réflexion de la conception des applications internet dont le besoin est de contrôler : - la logique d'enchaînement des pages - le contrôle d'accès aux services (traitements) - les appels aux services applicatifs - Ce modèle de conception impose donc une séparation en 3 couches : Le modèle : Il représente les données de l'application. Il définit aussi l'interaction avec la base de données et le traitement de ces données. La vue : Elle représente l'interface utilisateur, ce avec quoi il interagit. Elle n'effectue aucun traitement, elle se contente simplement d'afficher les données que lui fournit le modèle. Il peut tout à fait y avoir plusieurs vues qui présentent les données d'un même modèle. Le contrôleur : Il gère l'interface entre le modèle et le client. Il va interpréter la requête de ce dernier pour lui envoyer la vue correspondante. Il effectue la synchronisation entre le modèle et les vues. La synchronisation entre la vue et le modèle se passe avec le pattern Observer (Voir l'exemple 23) Il permet de générer des événements lors d'une modification du modèle et d'indiquer à la vue qu'il faut se mettre à jour. Voici un schéma des interactions entre les différentes couches : page 31/35

32 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 32/35 12/12/ :33:44 On trouve d'autres schémas de modèle MVC plus détaillés et adaptés au monde internet : Le monde Java (Servlets et JSP) : page 32/35

33 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 33/35 12/12/ :33:44 Schéma plus général : page 33/35

34 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 34/35 12/12/ :33: Exemple de MVC : l'exemple 23 Dans cet exemple ont se propose de créer un modèle qui gère un temps d'horloge basé sur l'horloge interne de l'ordinateur. Le modèle est décrit par une interface : public interface ModelHorloge Mise à jour de l'heure de l'horloge public void majheure(heurehorloge heure); Retourne l'heure de l'horloge public HeureHorloge getheure(); Change le nom de l'horloge public void renommer(string nom); Retourne le nom de l'horloge public String getnom(); Permet de s'abonner aux modifications des données public void addobserver(observer o); Le modèle utilise la classe Observable pour gérer les abonnements aux changements des données. Le contrôleur permet de réaliser les traitements qu'il sous-traite au modèle de données. Ces traitements sont appelés par le programme. L'interface du contrôleur est: Interface d'utilisation du controleur d'horloge public interface ControleurHorloge Changer le nom de l'horloge public void actionrenommerhorloge(string nomhorloge); Changer l'heure de l'horloge public void actionchangerheurehorloge(heurehorloge heure); Retourne le modele de l'horloge controlé par le controleur public ModelHorloge getmodelhorloge(); Le programme utilise 3 vues : Une vue pour afficher l'heure de l'horloge. L'heure est demandée à chaque fois par le programme. La vue est prévenu par notification de l' Observer du changement du nom de l'horloge public class VueAfficherHeureHorloge implements Observer Une vue pour saisir une nouvelle heure de l'horloge public class VueSaisirHeureHorloge Une vue pour saisir le nom de l'horloge public class VueSaisirNomHorloge Exemple d'un programme qui utilise l'horloge : page 34/35

35 NSY102-Chapitre-04_IntroductionAuxDesignPatterns.doc 35/35 12/12/ :33:44 public static void main2(string... args) Recupération du controleur ControleurHorloge controleur = ControleurHorlogeImpl. getinstance(); La vue est créé une seule fois. VueAfficherHeureHorloge vue2 = new VueAfficherHeureHorloge(); while(true) Saisie de l'heure VueSaisirHeureHorloge vue1 = new VueSaisirHeureHorloge(); HeureHorloge heure = vue1.saisir(); Changemment de l'heure controleur.actionchangerheurehorloge(heure); Saisie et changement du nom de l'horloge Le modele va prévenir la vue2 du changement VueSaisirNomHorloge vue3 = new VueSaisirNomHorloge(); controleur.actionrenommerhorloge(vue3.saisir()); Affichage de l'heure vue2.afficher(); Vous trouverez le programme complet sur le site : Exemple23_ModeleMVC 6. Conclusion Nous n'avons pas abordé tous les design patterns que nous avons lister en début de cette présentation car l'objectif n'était pas d'être exhaustif sur le sujet (on ne peut pas l'être) mais par la présentation de certains de montrer ce qu'est vraiment un design patterns et avec des exemples de décrire le codage de certains de ces design patterns. Nous avons vu que le design pattern n'est pas un élément du langage informatique comme une classe ou une instruction mais plutôt est ue bonen pratique de conception et de codage. L'objectif global de ces designs patterns est de rendre réutilisable des principes et des concepts en utilisant au mieux les propriétés des langages objets. Pas de panique!! Si vous ne vous sentez pas capable de programmer en Java en utilisant les design patterns cela n'est pas un handicape. Ce qui est important est de savoir qu'ils existent et vous les verrez à force de pratiquer. page 35/35