NFA035-Chapitre-02 LesDesignsPatterns.doc Chapitre 2 · Un design pattern est défini par : ... La solution est de créer une classe qui va servir de point central de création de

Programmation JAVA – NFA 035 Par J. LAFORGUE NFA035-Chapitre-02_LesDesignsPatterns.doc 1/39 25/03/2014 23:12:48

page 1/39

Chapitre 2

Les Design Patterns (ou Patron de Conception)

L'objectif de ce chapitre est d'utiliser les Designs Patterns comme outil de conception d'un programme objet. Une introduction à la notation UML est faite.

1. DEFINITIONS DU DP 3

1.1. LE « PATRON » 3

1.2. LE « CANEVAS » 4

2. LES MODELES DE CREATION 5

2.1. FABRIQUE DE CREATION (FACTORY ) 5

2.1.1. NOM ET ROLE 5

2.1.2. DESCRIPTION DU PROBLEME A RESOUDRE 6

2.1.3. DESCRIPTION DE LA SOLUTION 6

2.1.4. EXEMPLE DE FACTORY 7

2.2. LE SINGLETON 11




2.2.4. EXEMPLE DE SINGLETON 12

2.3. LE BUILDER 15




2.3.4. EXEMPLE DE BUILDER 16

3. LES MODELES DE STRUCTURE 20

3.1. L' ADAPTATEUR 21


3.1.2. COLLABORATION 21

3.1.3. CONVERSION 24

3.1.4. DEFAUT 25

3.2. LE PROXY 26




3.2.4. EXEMPLE DE PROXY 26

4. LES MODELES DE COMPORTEMENT 29


page 2/39

4.1. ITERATOR 29

4.2. BEAN 31

4.3. OBSERVER 31

4.3.1. SYNCHRONE MINIMAL 31

4.3.2. SYNCHRONE SUR CHANGEMENT D'ETAT 32

4.4. MVC 32



4.5. EXEMPLE DE MVC : L'EXEMPLE 01, 02, 03, 04 AVEC OBSERVER 35

5. CONCLUSION 37

6. ANNEXE A : LES VUES DU MODELE UML 38


page 3/39

1. Définitions du DP

1.1. Le « Patron » Les "patrons de conception" ou Design Patterns" sont des modèles standard et

réutilisables de conception d'une 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. 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.


page 4/39

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 ceux-ci 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

1.2. Le « Canevas »


page 5/39

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 « squelette » 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.

2. Les modèles de création Objectif : faire la création d'objet (instanciation) sans être nécessairement impacté

par l'évolution de la classe et de ses constructeurs.

2.1. Fabrique de création (Factory)

2.1.1. Nom et rôle Factory ou Usine de fabrication Une telle usine fabrique des objets, à la demande, au sens des LOO.


page 6/39

2.1.2. 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.

2.1.3. 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 7/39

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, …

2.1.4. 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 CarteGriseFac tory(); // Exemple de creation d'un objet du factor y // CarteGrise cg1 = usine.getInstance("LAFONT" , "PIERRE", "AM 613 H C");


page 8/39

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.s earch(str); for(CarteGrise cg : lcg) { System.out.println("------- ---------"); System.out.println(cg.toStr ing()); } } } }

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 Carte GriseImpl. // private Hashtable<String,CarteGriseImpl> carteg rises; // Constructeur de création de l'usine // public CarteGriseFactory()


page 9/39

{ cartegrises = new Hashtable<String,CarteGri seImpl>(); } // Creation d'une carte grise en fonction de ce rtaines 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 numeroPlaq ue) { CarteGriseImpl cg; cg = new CarteGriseImpl(nom,prenom,numeroPl aque); cartegrises.put(cg.getReference(),cg); return(cg); } // Recherche le morceau de chaine dans chacun d es attributs // de la carte grise // public ArrayList<CarteGrise> search(String crit ere) { ArrayList<CarteGrise> lcg = new ArrayList<C arteGrise>(); for(CarteGriseImpl cg : cartegrises.values( )) { String str = cg.toString(); if (str.toLowerCase().indexOf(crite re.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é po ur 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 10/39

this.prenom = prenom; this.numeroPlaque = numeroPlaque; this.date1ereMiseEnCirculation = Calendar.g etInstance(); // 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 ca ractere // public String toString() { return(this.nom+"\n"+ this.prenom+"\n"+ this.adresse+"\n"+ this.numeroPlaque+"\n"+ this.date1ereMiseEnCirculation.getTi me()+"\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.num eroPlaque;} public Calendar get1ereMiseEnCirculation(){ return this.date1ereMiseEnCirculation;} public String getReference(){return this.refere nce;} public String getAdresse(){return this.adresse; } public void setAdresse(String adresse){this.adr esse=adresse;} }


page 11/39

2.2. Le singleton

2.2.1. 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

2.2.2. 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. Permet de ne plus passer en paramètre l'objet du singleton

2.2.3. 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éé.


page 12/39

2.2.4. Exemple de Singleton CAS1 :

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 = 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 Carte GriseImpl. // private Hashtable<String,CarteGriseImpl> carteg rises; // Le constructeur est privé // private CarteGriseFactory() { cartegrises = new Hashtable<String,CarteGri seImpl>(); } // 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) {


page 13/39

// Creation du factory CarteGriseFactory usine = CarteGriseFactory.getUsine(); // Exemple de creation d'un objet du factor y // CarteGrise cg1 = usine.getInstance("LAFONT" , "PIERRE", "AM 613 H C"); System.out.println(cg1.toString()); // Deux autres créations : // usine.getInstance("DUPONT", "PAUL", "SM 312 HC");

CarteGriseFactory.getUsine().getInstance("GARRIC", "J EAN", "A M 234 AZ"); // Pour démontrer que c'est bien un singlet on // 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.toStr ing()); } } } }

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


page 14/39

// Chaque carte-grise est stocké dans une table de hashing dont la clef est

// une référence déterminée par la classe Carte GriseImpl. // private Hashtable<String,CarteGriseImpl> carteg rises; // Nom de l'usine // private String nomUsine; // Le constructeur est privé // private CarteGriseFactory(String nomUsine) { cartegrises = new Hashtable<String,CarteGri seImpl>(); this.nomUsine = nomUsine; } // Methode qui retourne le singleton // static public CarteGriseFactory getUsine(String nomUsine) { if (usine==null) 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 factor y // CarteGrise cg1 = usine.getInstance("LAFONT" , "PIERRE", "AM 613 H C"); 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 singlet on


page 15/39

// 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.toStr ing()); } } } }

2.3. Le builder

2.3.1. 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.

2.3.2. 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.


page 16/39

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".

2.3.3. 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

2.3.4. Exemple de builder // Programme principal du test du builder // public class MainBuilder { public static void main(String[] args) throws E xception { // Creation du builder // ---------------------------------------- ---------- CarteGriseBuilder builder = new CarteGriseB uilder(); // 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","123 DF56C"); System.out.println("------------"); System.out.println(cg1); // Construction d'une autre carte grise // ---------------------------------------- ---------- CarteGriseImpl cg2 = new CarteGriseImpl(); builder.initCarteGrise(cg2); builder.addIndividu("DURAND", "PIERRE",


page 17/39

"22 rue du point TOULOU SE 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() { carteGrise=null; } public void initCarteGrise(CarteGriseImpl cg) { carteGrise=cg; } public void addIndividu(String nom,String preno m,String adresse) { carteGrise.setIndividu(new Individu(nom,pre nom,adresse)); } public void addIndividu(String nom,String preno m) { carteGrise.setIndividu(new Individu(nom,pre nom,null)); } public void addIndividu(Individu ind) { addIndividu(ind.getNom(),ind.getPrenom(),in d.getAdresse()); } public void addImmatriculation(String numeroPla que) throws Exception { carteGrise.setImmatriculation(new Immatricu lation(numeroPlaque)); carteGrise.initReference(); } public void addVehicule(String marque,String ty pe,String serie) { carteGrise.setVehicule(new Vehicule(marque, type,serie)); } }

// La classe concrete d'implémentation d'une carte grise // public class CarteGriseImpl implements CarteGrise {


page 18/39

private static long compteur=0; // utilisé po ur 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 { if (this.immatriculation==null) throw new E xception("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 ca ractere // 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 = immatricula tion;} public void setVehicule(Vehicule vehicule){this .vehicule = vehicule;} // L'implémentation des methodes de l'interface // public String getNom(){return this.individu.get Nom();} 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(){retu rn

this.immatriculation.getDate1ereMiseEnCirculation() ;} public String getReference(){return this.refere nce;} }


page 19/39

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; } public void setAdresse(String adresse){this.adr esse=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.g etInstance(); } public String getNumeroPlaque(){return numeroPl aque;} public Calendar getDate1ereMiseEnCirculation(){ return

date1ereMiseEnCirculation;} public String toString() { return(this.numeroPlaque+"\n"+ this.date1ereMiseEnCirculation.getTi me()); } }

public class Vehicule { private String marque; private String type; private String serie;


page 20/39

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.s erie); } }

3. 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 explicitement 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.


page 21/39

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.

3.1. L'adaptateur

3.1.1. 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) - de définir des comportements par défaut pour des méthodes d'une interface. Analysons chacun de ces 3 cas.

3.1.2. 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(portableCompatibl e); System.out.println (""); /******************** Portable SonneEricSon ne ***************/ //on crée le portable et son adaptateur PortableSonneEricSonne portableSonne = new

PortableSonneEricSonne(20); AdaptateurSonneEricSonne adaptateurSonne = new AdaptateurSonneEricSonne(portableSonne) ;


page 22/39

//on donne le portable à charger mais en ut ilisant son adaptateur chargeur.brancherPortable(adaptateurSonne); System.out.println (""); /********************* Portable SamSaoule * ******************/ //on crée le portable et son adaptateur PortableSamSaoule portableSam = new Portabl eSamSaoule(); AdaptateurSamSaoule adaptateurSam = new AdaptateurSamSaoule(portableSam); //on donne le portable à charger mais en ut ilisant son adaptateur chargeur.brancherPortable(adaptateurSam); } } interface IChargeable { public void recharger(int voltage); } class Chargeur { // le voltage en sortie du chargeur private int voltage = 10; // branchement d'un portable pour le charger public void brancherPortable(IChargeable portab le) { System.out.println("branchement d'un portab le"); portable.recharger(voltage); } } //================================================= =============== // Un portable compatible avec l'interface IChargea ble // 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 i nstance // class PortableSonneEricSonne { // ne se recharge int volts; public PortableSonneEricSonne(int volts) { this.volts=volts; }


page 23/39

public void ChargerBatteries() { System.out.println ("Portable SonneEricSonn e 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); } } // ================================================ ========== // Les adaptateurs class AdaptateurSonneEricSonne implements IChargeab le { // référence sur le portable adapté private PortableSonneEricSonne telephone; public AdaptateurSonneEricSonne(PortableSonneEr icSonne 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 po rtable) { this.telephone = portable; } //le portable SamSaoule n'a besoin que de 5 vol ts public void recharger(int volts) { this.telephone.ChargerPortable(); } } Exécution : branchement d'un portable Portable Compatible en charge


page 24/39

voltage: 10 branchement d'un portable Portable SonneEricSonne en charge voltage: 20 branchement d'un portable Portable SamSaoule en charge voltage: 5

3.1.3. 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.

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 Conversion 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; }


page 25/39

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; public CircleImplPointAdapter( Circle c ) { this.c = c; } public int getX() { return c.getX(); } public int getY() { return c.getY(); } }

3.1.4. 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() {


page 26/39

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 // ============================================ =================== class GrilleWindowAdapter extends WindowAdapter { // Fermeture de la fenetre public void windowClosing(WindowEvent e) { // Arret du thread threadContinue = false; // Destruction de la fenetre fen.dispose(); } } }

3.2. Le Proxy

3.2.1. 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.

3.2.2. Description du problème à résoudre Ce type de structure vise à pouvoir changer l'objet cible sans changer l'objet source

(manipulé).

3.2.3. 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.

3.2.4. Exemple de Proxy Séparation de l'applicatif et de l'IHM


page 27/39

public class ExempleProxy { public static void main(String[] args) { Applicatif appImp = new ApplicatifImp(); ApplicatifProxy appProxy = new ApplicatifPr oxy(appImp); // Exemple d'utilisation du Proxy // Separation de l'ihm et de son applicatif Ihm ihm = new Ihm(appProxy); ihm.exemple(); } } class Ihm { 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()


page 28/39

{ 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(); } 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 29/39

Pour mieux illustrer, l'usage de ce design pattern, on peut aller voir l'exemple 01

(ancien 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.

4. 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

4.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.*;


page 30/39

public class MyIteratorExemple { public static void main(String[] args) { ListeLivre livres = new ListeLivre("Fantast iques"); livres.ajouterLivre("Les dragons de l'auror e"); 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(); } 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; }


page 31/39

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

4.2. 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 et serialisation.

4.3. Observer Observer ou observateur Le rôle de ce DP est de prévenir un utilisateur du changement d'état d'un objet cible. Il existe différentes formes d'observateur en fonction de l'impact sur l'objet cible et/ou

du mode synchrone ou asynchrone de l'observation : - synchrone minimal - synchrone sur changement d'état

4.3.1. Synchrone minimal Ce DP sert de base à tout les Observer. Les principes sont les suivants :

Chaque utilisateur s'abonne à l'objet cible (à travers "Observable")

L'utilisateur crée un "Observer" qui est vu pas l'Observable sous la forme d'une Interface

L'Observable notifie chaque Observer du changement de son état

Il y a au moins autant d'Observer qu'il existe d'objet cible


page 32/39

Observer

void update(Observable o, Object arg)

Utilisateur ObservableAppObserverApp

void update(Observable o, Object arg)

App

Observable

void addObserver(Observer o)void notifyObservers(Object arg)

Voir sur le site http://jacques.laforgue.free.fr l’exemple Exemple16a_DPObserverSimple

La notification aux observateurs est synchrone. Cela implique que, tant que les observateurs n'ont pas finis leurs méthodes de mise

à jour (méthode update) alors l'objet cible est en attente.

4.3.2. Synchrone sur changement d'état Pour économiser les notifications, on sépare les notions de changement d'état et de

notification :

chaque changement d'état mais à jour un booléen précisant qu'il y a eu au moins 1 changement d'état

un changement d'état particulier (il peut ne pas être le seul) teste s'il y a eu au moins un changement d'état. Et si c'est le cas alors réalise la notification aux observateurs

Voir sur le site http://jacques.laforgue.free.fr l’exemple Exemple16b_DPObserverEtat

En JAVA, comme l'exemple le démontre, la classe Observable permet cette gestion

de changement d'état :

la méthode setChanged() permet de préciser qu'il y a eu au moins 1 changement

la méthode notifyObservers() notifie les observateurs que s'il y a eu au moins un changement.

4.4. MVC

4.4.1. Nom et rôle Modèle-Vue-Contrôleur


page 33/39

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).

4.4.2. 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 (package) : 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 de l'applicatif, 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 07) 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 34/39

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) :

Schéma plus général :


page 35/39

4.5. Exemple de MVC : l'exemple 01, 02, 03, 04 avec Observer 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. Les 3 vues ci-dessous sont créées. Ensuite un programme principal utilise ces vues

pour afficher l'heure de l'horloge, mettre l'heure à jour de l'horloge et changer le nom de l'horloge.

La vue d'affichage de l'heure de l'horloge est prévenue des modifications du modèle

(heure et nom) par notification. Les vues de saisi de l'heure et le nom de l'horloge passe par le contrôleur pour

réaliser les actions. Aucune des vues n'ont de lien avec le modèle.


page 36/39

VueAfficherHeureHorloge

VueSaisirHeureHorloge

VueSaisirNomHorloge ControleurHorlogeImpl

ModelHorlogeImpl

heureHorloge

nomHorloge

notifications

actionChangerHeureHorloge

actionChangerNomHorloge

actionNotifier

renommermajHeure notifier

Vous trouverez le programme complet sur le site sous la forme de 3 exemples : Exemple01_ModeleMVC Exemple d'implementation du probleme de l'horloge suivant un modele MVC dans

lequel la vue est notifie des changements d'etat de l'horloge, nom et heure, par un observable et observer.

Exemple02_ModeleMVC Variante de l'exemple précédent : autant d'Observable/Observer que de données

différentes a notifier. Exemple03_ModeleMVC Variante de l'exemple précédent : toutes les informations notifiées sont dans un et un

seul objet passé en paramètre de la méthode update de l'observer.


page 37/39

Dans l'exemple 03, on obtient le schéma UML suivant :

Observer

update

VueAfficherHeureHorlogeObservableHorloge

void notifier(DataHorlogedata)

ObserverHorloge

update

ModelHorloge

nomheure

Observable

addObservernotifyObservers

ControleurHorlogeImpl

getInstance

ControleurHorloge

controleurHorlogeSingleton

VueSaisirHeureHorloge

VUE

CONTROLEUR

MODELE

Runnable

void run()

5. 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 une bonne 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 38/39

6. ANNEXE A : Les vues du modèle UML


page 39/39

Documents

NFA035-Chapitre-02 LesDesignsPatterns.doc Chapitre 2 · Un design pattern est défini par : ... La solution est de créer une classe qui va servir de point central de création de