Architecture logicielle

Les patrons de conception III

Patterns de responsabilit (suite)

MEDIATOR
PROXY
CHAIN OF RESPONSABILITY
FLYWEIGHT

MEDIATOR
Lobjectif du pattern MEDIATOR est de dfinir un
objet qui encapsule la faon dont un ensemble
dobjets interagissent. Cela promeut un couplage
lche, vitant aux objets davoir se rfrer
explicitement les uns aux autres, et permet de
varier leur interaction indpendamment.

Scnario
X possde une maison entirement automatise laide de code
Java grce aux bons services de MaisonsDuFutur.
Tous ses appareils sont conus pour lui faciliter la vie. Quand X
cesse de taper sur le bouton darrt de son rveil, ce dernier dit
la cafetire de commencer faire le caf. Mais mme si X a la
belle vie, lui et les autres clients ne cessent de rclamer de
nouvelles fonctionnalits : pas de caf le week-end... arrter
larrosage automatique si une averse est annonce... mettre le
rveil plus tt les jours de ramassage des encombrants...
Problme : Il devient vraiment trs difficile de mmoriser dans
quels objets se trouvent les rgles et comment les objets sont lis
les uns aux autres.

Scnario

Solution
Lajout dun Mdiateur au systme permet de simplifier
grandement tous les appareils :
Ils informent le mdiateur quand leur tat change.
Ils rpondent aux requtes du Mdiateur.

Avant linsertion du Mdiateur, tous les appareils devaient se

connatre... ils taient troitement coupls.
Avec le Mdiateur en place, ces objets sont totalement dcoupls
les uns des autres.
Le Mdiateur contient toute la logique de contrle pour
lensemble du systme. Quand un appareil existant a besoin
dune nouvelle rgle ou quand un nouvel appareil est ajout au
systme, vous savez que toute la logique ncessaire sera ajoute
au Mdiateur.

Solution

Avantages
Augmente la rutilisabilit des objets pris en charge par le
Mdiateur en les dcouplant du systme.
Simplifie la maintenance du systme en centralisant la
logique de contrle.
Simplifie et rduit la varit des messages changs par les
diffrents objets du systme.

Emplois et inconvnients
Mdiateur est couramment employ pour coordonner des
composants dIHM.
En labsence de conception soigneuse, lobjet Mdiateur luimme peut devenir exagrment complexe.

Exercice
Pour ce qui est dextraire une logique dune classe ou dune
hirarchie existante afin de la placer dans une nouvelle classe,
MEDIATOR ressemble dautres patterns. Citez deux autres
patterns pouvant impliquer une telle refactorisation.

10

PROXY
Lobjectif du pattern PROXY est de contrler laccs
un objet en fournissant un intermdiaire pour cet
objet.
On utilise le pattern Proxy pour crer un objet remplaant
qui contrle laccs un autre objet qui peut tre distant,
coteux crer ou qui doit tre scuris.
On distingue 3 proxy :
Un proxy distant contrle laccs un objet distant.
Un proxy virtuel contrle laccs une ressource dont la
cration est coteuse.
Un proxy de protection contrle laccs une ressource en
fonction de droits daccs.
11

Diagramme de classes

12

Exemple : Afficher des pochettes de CD

Supposons que vous vouliez crire une application qui affiche les
pochettes de vos CD favoris.
Vous pouvez crer un menu des titres de CD puis rcuprer les
images sur un service en ligne comme Amazon.com.
Un seul problme : selon la charge du rseau et le dbit de votre
connexion, le chargement dune pochette de CD peut prendre un
certain temps.
Votre application doit donc afficher quelque chose pendant que
vous attendez.
Une fois limage charge, le message doit disparatre et vous devez
voir limage.
Pour ce faire, un moyen pratique consiste utiliser un proxy
virtuel.
13

14

Concevoir le Proxy Virtuel pour les

pochettes

15

Comment ProxyDImage va fonctionner :

ProxyDImage cre dabord une ImageIcon et commence la
charger partir dune URL donne.
Pendant quil rcupre les octets qui composent limage,
ProxyDImage affiche Chargement en cours, patientez.
Lorsque limage est entirement charge, ProxyDImage
dlgue tous les appels de mthode ImageIcon, notamment
paintIcon(), getWidth() et getHeight().
Si lutilisateur demande une nouvelle image, nous crons un
nouveau proxy et nous rptons le processus.

16

17

CHAIN OF RESPONSABILITY
Lobjectif du pattern CHAIN OF RESPONSABILITY
est dviter de coupler lmetteur dune requte
son rcepteur en permettant plus dun objet dy
rpondre.
Utilisez le pattern Chane de responsabilit quand vous
voulez donner plus dun objet une chance de traiter une
requte.

18

Scnario
Distribon reoit plus de courrier lectronique quil ne peut en
grer depuis la sortie de leurs distributeurs de bonbons quips de
Java.
Selon leur propre analyse, ils reoivent quatre types de courrier :
des lettres de fans qui adorent leur nouveau jeu,
des rclamations de parents dont les gosses sont accros au jeu
des demandes de mise en place de nouveaux distributeurs.
Ils reoivent galement pas mal de spams.

Tout le courrier des admirateurs est transmis directement au

P.D.G., les plaintes au service juridique et les demandes de
nouveaux distributeurs au service dveloppement. Les messages
indsirables doivent tre dtruits.
19

Votre tche
Distribon a dj crit des dtecteurs intelligents qui peuvent
distinguer une lettre de fan dun spam, dune rclamation ou
dune demande
Mais ils ont besoin de vous pour crer une conception qui
permette aux dtecteurs de grer le courrier entrant.

20

Comment utiliser le pattern Chane de

responsabilit ?
Avec le pattern Chane de responsabilit, vous crez une chane dobjets
qui examinent une requte.
Chaque objet considre la requte son tour et la traite ou la transmet
lobjet suivant dans la chane.
Quand un message est reu, il est transmis au premier gestionnaire :
GestionnaireSpams. Si GestionnaireSpams ne peut pas traiter la requte,
il la transmet GestionnaireFans et ainsi de suite...

21

Avantages
Dcouple lmetteur de la requte de ses rcepteurs.
Simplifie votre objet, car il na pas besoin de connatre la
structure de la chane ni de conserver des rfrences directes
ses membres.
Permet dajouter ou de supprimer dynamiquement des
responsabilits en changeant les membres ou lordre de la
chane.

22

Emplois et inconvnients
Couramment utilis dans les interfaces graphiques pour grer
des vnements comme les clics de souris ou les entres au
clavier.
Lexcution de la requte nest pas garantie : elle peut
chouer si aucun objet ne la traite (ce qui peut tre un
avantage ou un inconvnient).
Lobservation des caractristiques lexcution et le
dboguage peuvent tre difficiles.

23

FLYWEIGHT
Le pattern FLYWEIGHT laisse plusieurs clients se partager
un grand nombre de petits objets : les flyweights (poids
mouche). Pour que cela fonctionne, vous devez considrer que
lorsquun client change ltat dun objet, cet tat est modifi
pour chaque client ayant accs lobjet.
Lobjectif du pattern FLYWEIGHT est dutiliser le
partage pour supporter efficacement un grand
nombre dobjets forte granularit.

24

Un scnario
Vous avez crit une super application de
conception paysagre qui permet
notamment dajouter des arbres autour
dune maison.
Dans cette application, les arbres ne font
pas grand-chose : ils ont un emplacement
X-Y et savent se dessiner eux-mmes
dynamiquement en fonction de leur ge.
Le problme est quun utilisateur peut
vouloir dimportantes quantits darbres
dans lun de ses plans paysagers.
25

Pourquoi utiliser le pattern Poidsmouche ?

Si un client va acheter mille licences de votre application et
utiliser votre logiciel pour raliser les tudes paysagres de
quartiers entiers. Aprs avoir test ce logiciel, le client se
plaint que lapplication commence ramer srieusement
Et si au lieu davoir des milliers dobjets Arbre vous pouviez
reconcevoir votre systme de faon navoir quune seule
instance dArbre et un objet client qui maintiendrait ltat de
TOUS vos arbres ? Eh bien cest le pattern Poids-mouche !

26

Pourquoi utiliser le pattern Poidsmouche ?

27

Avantages
Rduit le nombre dinstances prsentes au moment de
lexcution et conomise de la mmoire.
Centralise ltat de nombreux objets virtuels .

28

Emplois et inconvnients
On utilise flyweight lorsquune classe a de nombreuses
instances qui peuvent toutes tre contrles de manire
identique.
Un inconvnient de flyweight est que, une fois que vous
lavez implment, les instances logiques individuelles de la
classe ne sont plus capables de se comporter
indpendamment des autres instances.

29

Patterns de construction
Introduction la construction
BUILDER

30

Introduction la construction
Lorsque vous crez une classe Java, vous prvoyez
normalement une fonctionnalit pour la cration des objets
en fournissant un constructeur.
Un constructeur est cependant utile uniquement si les clients
savent quelle classe instancier et disposent des paramtres
que le constructeur attend.
Plusieurs patterns de conception peuvent intervenir dans les
situations o ces conditions, ou dautres circonstances de
construction ordinaire, ne valent pas.

31

Les principaux patterns de

construction

Les patterns de construction permettent un client de construire un

nouvel objet par lintermdiaire de moyens autres que lappel
dun constructeur de classe.
32

BUILDER (Monteur)
Vous ne disposez pas toujours de toutes les informations
ncessaires pour crer un objet lorsque vient le moment de
le construire.
Il est particulirement pratique de permettre la construction
progressive dun objet, au rythme de lobtention des
paramtres pour le constructeur, comme cela se produit avec
lemploi dun analyseur syntaxique ou avec une interface
utilisateur.
Lobjectif du pattern BUILDER est de dplacer la
logique de construction dun objet en dehors de la
classe instancier.
33

Un scnario
On vient de vous confier le dveloppement dun logiciel de
planification de sjours pour Patternsland, un nouveau parc
thme rcemment construit aux portes dObjectville.
Les htes du parc peuvent choisir un htel et diffrents types
de tickets dadmission, rserver des tables au restaurant et
mme des places des vnements spciaux. Pour crire ce
programme, vous devez pouvoir crer des structures telles
que :

34

35

Pourquoi utiliser le pattern Builder ?

Le planning de chaque hte peut comprendre un nombre de
journes et des types dactivits variables.
Il vous faut donc une structure de donnes souple et capable de
reprsenter les plannings des htes avec toutes leurs variantes.
Vous devez galement observer une squence dtapes
potentiellement complexes pour crer le planning.
Vous souvenez-vous dItrateur ?

36

Nous avions encapsul litration dans un objet distinct et cach la

reprsentation interne de la collection au client.
Lide est la mme ici : nous encapsulons la cration du planning
dans un objet (appelons-le un monteur) et notre client demandera
au monteur de construire la structure du planning sa place.

37

Avantages
Encapsule la faon dont un objet complexe est construit.
Permet de construire des objets en plusieurs tapes selon un
processus variable .
Masque la reprsentation interne du produit au client.
Les implmentations des produits sont interchangeables
parce que le client ne voit quune interface abstraite.

38

Emplois et inconvnients
Souvent employ pour crer des structures composites.
La construction des objets demande plus de connaissance du
domaine du client que lemploi dune Fabrique (pattern
suivant).

39