Vous êtes sur la page 1sur 39

Architecture logicielle

Les patrons de conception

Plan
Introduction
Les patrons dinterface

QuestQuest-ce quun pattern ?


Un pattern, ou modle, est un moyen daccomplir quelque
chose, un moyen datteindre un objectif, une technique.
Le principe est de compiler les mthodes prouves qui
sappliquent de nombreux types defforts, tels que la
fabrication daliments, dartifices, de logiciels, ou autres.
La communaut informatique a fait sienne cette approche en
crant de nombreux ouvrages qui documentent des modles
de dveloppement logiciel. Ces livres consignent les
meilleures pratiques en matire de processus logiciels,
danalyse logicielle, darchitecture de haut niveau, et de
conception de niveau classe.
3

QuestQuest-ce quun pattern de conception ?


Un pattern de conception (design pattern) est un modle
qui utilise des classes et leurs mthodes dans un langage orient
objet.
Les dveloppeurs commencent souvent sintresser la
conception seulement lorsquils matrisent un langage de
programmation et crivent du code depuis longtemps.
Les patterns de conception interviennent un niveau au-dessus
du code et indiquent typiquement comment atteindre un but
en nutilisant que quelques classes.
Un pattern reprsente une ide, et non une implmentation
particulire.
4

Pourquoi ?
Dautres dveloppeurs ont dcouvert avant vous comment
programmer efficacement dans les langages orients objet.
Si vous souhaitez devenir un programmeur Java avanc, vous
devriez tudier les patterns de conception.
On dnombre au moins cent patterns qui valent la peine
dtre connus.
On se limitera ltude de 23 patrons

Patterns dinterface
ADAPTER : fournit linterface quun client attend en
utilisant les services dune classe dont linterface est
diffrente.
FACADE : fournit une interface simplifiant lemploi dun
sous-systme.
COMPOSITE : permet aux clients de traiter de faon
uniforme des objets individuels et des compositions dobjets.
BRIDGE : dcouple une classe qui sappuie sur des
oprations abstraites de limplmentation de ces oprations,
permettant ainsi la classe et son implmentation de varier
indpendamment.
6

Patterns de responsabilit
SINGLETON : garantit quune classe ne possde quune seule instance, et fournit
un point daccs global celle-ci.
OBSERVER : dfinit une dpendance du type un--plusieurs (1,n) entre des objets
de manire ce que lorsquun objet change dtat, tous les objets dpendants en
soient notifis et soient actualiss afin de pouvoir ragir conformment.
MEDIATOR : dfinit 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.
PROXY : contrle laccs un objet en fournissant un intermdiaire pour cet objet.
CHAIN OF RESPONSABILITY : vite de coupler lmetteur dune requte son
rcepteur en permettant plus dun objet dy rpondre.
FLYWEIGHT : utilise le partage pour supporter efficacement un grand nombre
dobjets forte granularit.
7

Patterns de construction
BUILDER : dplace la logique de construction dun objet endehors de la classe instancier, typiquement pour permettre une
construction partielle ou pour simplifier lobjet.
FACTORY METHOD : laisse un autre dveloppeur dfinir
linterface permettant de crer un objet, tout en gardant un
contrle sur le choix de la classe instancier.
ABSTRACT FACTORY : permet la cration de familles dobjets
ayant un lien ou interdpendants.
PROTOTYPE : fournit de nouveaux objets par la copie dun
exemple.
MEMENTO : permet le stockage et la restauration de ltat dun
objet.
8

Patterns dopration
TEMPLATE METHOD : implmente un algorithme dans une mthode,
laissant dautres classes le soin de dfinir certaines tapes de
lalgorithme.
STATE : distribue la logique dpendant de ltat dun objet travers
plusieurs classes qui reprsentent chacune un tat diffrent.
STRATEGY : encapsule des approches, ou stratgies, alternatives dans
des classes distinctes qui implmentent chacune une opration
commune.
COMMAND : encapsule une requte en tant quobjet, de manire
pouvoir paramtrer des clients au moyen de divers types de requtes (de
file dattente, de temps ou de journalisation) et de permettre un client
de prparer un contexte spcial dans lequel mettre la requte.
INTERPRETER : permet de composer des objets excutables daprs
un ensemble de rgles de composition que vous dfinissez.

Patterns dextension
DECORATOR : permet de composer dynamiquement le
comportement dun objet.
ITERATOR : fournit un moyen daccder de faon
squentielle aux lments dune collection.
VISITOR : permet de dfinir une nouvelle opration pour
une hirarchie sans changer ses classes.

10

Patterns dinterface
Introduction aux interfaces
ADAPTER
FACADE
COMPOSITE

11

Introduction aux interfaces


Linterface dune classe est lensemble des mthodes et
champs de la classe auxquels des objets dautres classes sont
autoriss accder.
Limplmentation dune classe est le code contenu dans
ses mthodes.
Les interfaces Java permettent plusieurs classes doffrir la
mme fonctionnalit et une mme classe dimplmenter
plusieurs interfaces.

12

Interfaces et classes abstraites


Si les interfaces nexistaient pas, vous pourriez utiliser la
place des classes abstraites, comme dans C++.
Les interfaces jouent toutefois un rle essentiel dans le
dveloppement dapplications multiniveaux, ce qui justifie
certainement leur statut particulier de structure distincte.

13

Exemple
Considrez la dfinition dune interface que les classes de simulation de
fuse doivent implmenter.
Les ingnieurs conoivent toutes sortes de fuses, quelles
soient combustible solide ou liquide, avec des caractristiques
balistiques trs diverses. Indpendamment de sa composition, la
simulation dune fuse doit fournir des chiffres pour la pousse (thrust)
et la masse (mass).
Voici le code quutilise Oozinoz pour dfinir linterface de simulation de
fuse :
package com.oozinoz.simulation;
public interface RocketSim {
abstract double getMass();
public double getThrust();
void setSimTime(double t);}
14

Exercice 1
Parmi les affirmations suivantes, lesquelles sont vraies ?
Les mthodes de linterface RocketSim sont toutes trois abstraites, mme si
seulement getMass() dclare cela explicitement.
Les trois mthodes de linterface sont publiques, mme si seulement
getThrust() dclare cela explicitement.
Linterface est dclare public interface, mais elle serait publique mme si le
mot cl public tait omis.
Il est possible de crer une autre interface, par exemple RocketSimSolid, qui
tende RocketSim.
Toute interface doit comporter au moins une mthode.
Une interface peut dclarer des champs dinstance quune classe
dimplmentation doit galement dclarer.
Bien quil ne soit pas possible dinstancier une interface, une interface peut
dclarer des mthodes constructeurs dont la signature sera donne par une
classe dimplmentation.
15

Interfaces et obligations
Un avantage important des interfaces Java est quelles limitent
linteraction entre les objets.
Une classe qui implmente une interface peut subir des
changements considrables dans sa faon de remplir le contrat
dfini par linterface sans que cela affecte aucunement ses clients.
Un dveloppeur qui cre une classe implmentant RocketSim a pour
tche dcrire les mthodes getMass() et getThrust() qui retournent
les mesures de performance dune fuse. Autrement dit, il doit
remplir le contrat de ces mthodes.
Parfois, les mthodes dsignes par une interface nont aucune
obligation de fournir un service lappelant. Dans certains cas, la
classe dimplmentation peut mme ignorer lappel, implmentant
une mthode avec un corps vide.
16

AuAu-del des interfaces ordinaires

17

Oozinoz
Les exercices et exemples de cette partie citent tous des
exemples dOozinoz Fireworks, une entreprise fictive qui
fabrique et vend des pices pour feux dartifice et organise
des vnements pyrotechniques. Vous pouvez vous procurer
le code de ces exemples ladresse www.oozinoz.com.

18

ADAPTER
Un objet est un client lorsquil a besoin dappeler votre
code.
Si une classe existante est en mesure dassurer les services
requis par un client mais que ses noms de mthodes
diffrent, vous pouvez appliquer le pattern ADAPTER.
Lobjectif du pattern ADAPTER est de fournir
linterface quun client attend en utilisant les
services dune classe dont linterface est diffrente.

19

Adaptation une interface


Soit une classe cliente qui invoque une mthode
mthodeRequise() dclare dans une interface.
Supposez que vous avez trouv une classe existante avec une
mthode nomme par exemple mthodeUtile() capable de
rpondre aux besoins du client.
Vous pouvez alors adapter cette classe au client en crivant une
classe qui tend ClasseExistante, implmente InterfaceRequise et
redfinit mthode-Requise() de sorte quelle dlgue ses
demandes mthodeUtile().
La classe NouvelleClasse est un exemple de ADAPTER. Une
instance de cette classe est une instance de InterfaceRequise. En
dautres termes, NouvelleClasse rpond aux besoins du client.
20

Exemple

21

Exemple Oozinoz (1)


Imaginez que vous travailliez avec
un package qui simule le vol et le
minutage de fuses comme celles
fabriques par Oozinoz.
Ce package inclut un simulateur
dvnements qui couvre les
effets du lancement de plusieurs
fuses, ainsi quune interface qui
spcifie le comportement dune
fuse.

22

Exemple Oozinoz (2)


Vous disposez dune classe PhysicalRocket que vous voulez inclure dans la
simulation.
Cette classe possde des mthodes qui correspondent approximativement
au comportement requis par le simulateur.
Vous pouvez donc appliquer ADAPTER en drivant de PhysicalRocket une
sous-classe qui implmente linterface RocketSim.

23

Adaptateurs de classe et dobjet


Les conceptions prcdentes sont des adaptateurs de classe,
cest--dire que ladaptation procde de la drivation de sousclasses. Dans une telle conception, la nouvelle classe
adaptateur implmente linterface dsire et tend
une classe existante.
Cette approche ne fonctionne pas toujours, notamment
lorsque lensemble de mthodes que vous voulez adapter
nest pas spcifi dans une interface.
Dans ce cas, vous pouvez crer un adaptateur dobjet,
cest--dire un adaptateur qui utilise la dlgation plutt
que la drivation de sous-classes.
24

Exemple

25

Exemple Oozinoz (1)


Imaginez que le package de
simulation fonctionne
directement avec une classe
Skyrocket, sans spcifier
dinterface dfinissant les
comportements ncessaires
pour la simulation
Dans cette conception-ci, le
package com.oozinoz.simulation
ne spcifie pas linterface dont il
a besoin pour modliser une
fuse.
26

Exemple Oozinoz (2)


La classe Skyrocket utilise un modle physique assez
rudimentaire. Par exemple, elle part du principe que la fuse
se consume entirement mesure que son carburant brle.
Supposez que vous vouliez appliquer le modle plus
sophistiqu offert par la classe PhysicalRocket dOozinoz.
Pour adapter la logique de cette classe la simulation, vous
pourriez crer une classe OozinozSkyrocket en tant
quadaptateur dobjet qui tend Skyrocket et utilise un objet
PhysicalRocket, comme le montre la Figure sivante :

27

Exemple Oozinoz (3)


Une fois complt, ce
diagramme reprsentera la
conception dun
adaptateur dobjet qui
sappuie sur les
informations dune classe
existante pour satisfaire le
besoin dun client
dutiliser un objet
Skyrocket.

28

En tant quadaptateur dobjet, la classe OozinozSkyrocket tend


Skyrocket, et non PhysicalRocket. Cela permet un objet
OozinozSkyrocket de servir de substitut chaque fois que le client
requiert un objet Skyrocket.
La classe Skyrocket supporte la drivation de sous-classes en
dfinissant sa variable simTime comme tant protected.

Un objet OozinozSkyrocket
est un objet Skyrocket, mais
son travail est ralis par
transmission des appels
un objet PhysicalRocket.
29

Exercice 2
Imaginez que vous souhaitiez lister
quelques fuses dans une table en
utilisant une interface utilisateur Swing.
Donnez la classe
RocketTableModel qui adapte un
tableau de fuses linterface
attendue par TableModel.
Exemple :

30

Pour rsumer

31

Pour rsumer

32

FACADE
Un gros avantage de la POO est quelle permet dviter le
dveloppement de programmes monolithiques au code
irrmdiablement enchevtr.
Dans un systme OO, une application est, idalement, une
classe minimale qui unit les comportements dautres classes
groupes en kits doutils rutilisables (packages).
Lobjectif du pattern FACADE est de fournir une
interface simplifiant lemploi des classes dun
package ou dun sous-systme.

33

Faades, utilitaires et dmos


Une classe de faade peut ne contenir que des mthodes
statiques, auquel cas elle est appele un utilitaire.
Une dmo est un exemple qui montre comment employer
une classe ou un sous-systme. A cet gard, la valeur des
dmos peut tre vue comme tant gale celle des faades.

34

Exemple HOME CINEMA

35

Pour regarder un film

Quand le fim est terminer il faut tout refaire lenvers !!


36

Construire le faade de votre H C

37

Implmenter linterface simplifier

38

Tester

39