Design Patterns Java 1222499509564319 8

B.
Vinot
Design Patterns JAVA

Conception dapplications objet
Contenu du cours
Introduction aux DP Autres Patterns Principes fondamentaux de conception Les Patterns d'analyse Les patterns GRASS Le Raii Ouverture-Fermeture (OCP) Organisation Inversion des dpendances (DIP) MVC Substitution de Liskov (LSP) Les frameworks Sparation des interfaces (ISP) Les composants Mthodes de DVP et Processus Les packages Up XP Mtriques Tests et Refactoring Les design patterns Les DP du GOF (23) Comportement (11) Structure (7) Cration (5)
Pourquoi faire de l'objet(1) ?

Increased Productivity 5 2 2 6 7 11 14 17 17 11 8 Software reuse Improved interfaces Cost savings
Improved application maintenance Encapsulate existing applications Develop strategic applications quickly Develop applications as revenue source Access new OS and tools
Pourquoi faire de l'objet(2) ?

Average Function LOC Average Function LOC Min Function LOC Min Function LOC Avg Cyclomatic Complex Avg Cyclomatic Complex Avg Comparison Complex Avg Comparison Complex Avg Logic Flow Complex Avg Logic Flow Complex Avg Function Complexity Avg Function Complexity eLoc/100 eLoc/100 eLOC eLOC C++ C++ V0 V0 6,66 6,66 2 2 1,66 1,66 0,25 0,25 1,91 1,91 3,69 3,69 2,07 2,07 207 207 C++ C++ V1 V1 6,2 6,2 1 1 1,59 1,59 0,24 0,24 1,83 1,83 3,59 3,59 2,5 2,5 250 250 C++ C++ V2 V2 6,11 6,11 1 1 1,59 1,59 0,3 0,3 1,89 1,89 3,7 3,7 2,68 2,68 268 268 C C V0 V0 29,62 29,62 3 3 5,88 5,88 1,38 1,38 7,25 7,25 9 9 2,68 2,68 268 268 C C V1 V1 32,5 32,5 3 3 6,25 6,25 1,62 1,62 7,88 7,88 9,62 9,62 2,91 2,91 291 291 C C V2 V2 37,11 37,11 3 3 6,56 6,56 2,22 2,22 8,78 8,78 10,56 10,56 3,53 3,53 353 353
Introduction aux Design Patterns

Les Patterns GRASS General ResponsabilityAssignement Software Patterns
Les Patterns : Introduction
Naissance des patterns : Les patterns furent utiliss bien avant que les systmes dinformations modernes napparaissent, dans dautres disciplines comme la construction et larchitecture de btiments.
1987, Beck et Cunningham dfinissent des patterns pour interfaces utilisateurs. 1994 : Design Patterns : Elements of reusable object oriented software Gof pour Gang of Four (Gamma, Helm, Johnson et Vlissides)
Craig Larman dcrit des modles de conception plus intuitifs : les Patterns GRASP : General Responsability Assignement Software Patterns, ou patterns gnraux daffectation des responsabilits.
Les Patterns : Dfinition

Un design pattern est un modle de conception. Au fur et mesure des dveloppements, des principes gnraux rptitifs sont remarqus, et des solutions courantes sont identifies. En formalisant celles-ci, sous la forme de la prsentation dun problme de conception, et de la solution pour le rsoudre, on obtient un design Pattern. Un design pattern doit rpondre certains aspects essentiels : Un pattern a un nom vocateur, qui reprsente bien lessence mme de son existence. Exemple : le pattern GoF Singleton Un pattern rsout un problme. Exemple : une classe ne peut avoir quune et une seule instance disponible. Un pattern fourni une solution-gnie (voir le pattern singleton plus loin) Un pattern doit tre expliqu (documentation-uml)
Exemple : Les Patterns Grasp
Cest presque du bon sens Lexpert (affectation des responsabilits) Le crateur Faible couplage Forte cohsion Contrleur
Le pattern GRASP : Expert

Qui fait quoi : le modle Expert est un pattern relativement intuitif, qui en gnral, est respect par le bon sens du concepteur. Il sagit tout simplement daffecter une classe les responsabilits correspondants aux informations dont elle dispose intrinsquement (quelle possde) ou non ( objets de collaborations ). on ne peut exiger dun rfrigrateur quil fasse radiateur et rangedisques Donner des dfinitions (c'est trs difficile) Voiture Maison +voilure +age int i; // variable i entire +surface +queue
Personne -nom: String -age: int +Metro() +Boulot() +Dodo()
+poids +vitesse +pente +lit +lampe +Rouler() +Voler() +Manger() +Travailler() +Allumer() +Vendre() +Vieillir() +Dormir()
Le pattern GRASP : Crateur

Qui cre qui? : Ce pattern consiste en la dtermination de la responsabilit de la cration dune instance dune classe par une autre. Une classe A agrge des instances de la classe B Une classe A contient des instances de la classe B Une classe A utilise des instances dune classe B Une classe A possde les donnes ncessaires linitialisation des instance de classe B, etc. Variables globales! Notion de configurateur Dlguer la fabrication qq dautre! Persistance (JDBC,DAO)
10
Le pattern GRASP : Couplage

Le couplage exprime la relation troite quun lment (Classe, Systme ou sous systme) entretien avec un ou des autres lments. Un lment faiblement coupl ne possde pas ou peu de dpendances vis a vis dautres lments. Les objets sont coupls (paresseux) Un objet qui est connu de personne est inutile. Un objet qui connat personne ne fait pas grand chose (sauf Utility) Parler des classes abstraites plus tt qu des classes concrtes
11
Le pattern GRASP : Cohsion

Esprit de famille La cohsion mesure le degr de spcialisation des responsabilits dun composant / classe. La cohsion mdiocre altre la comprhension, la rutilisation, la maintenabilit et subit toute sorte de changements. Exception pour Corba, RMI, ..(pb de granularit)
Personne
Logement
Vehicule
12
Le pattern GRASP : Contrleur

Le contrleur contrle. Il est entre la vue et les entits (MVC) Une classe Contrleur doit tre cre si elle rpond lun des cas suivants
La classe reprsente une contrleur de faade, cest dire linterface daccs lensemble dun systme. La classe reprsente le scnario dun cas dutilisation. On le nomme en gnral Session , et est charg de traiter tous les vnements systmes contenus dans un scnario de cas dutilisation. Un contrleur contient : Ce qui ne concerne pas la vue Ce qui ne concerne pas les entits (Expert)
13
Principes fondamentaux de conception
Ouverture-Fermeture OCP Inversion des dpendances DIP Substitution de Liskov LSP Sparation des interfaces ISP
14
Les objectifs du DESIGN

viter les phnomnes de dgnrescence de l'application Du point de vue du design, trois risques principaux pnalisent les activits de dveloppement : La rigidit : chaque volution est susceptible d'impacter de nombreuses parties de l'application Extensibilit.
La fragilit : la modification d'une partie de l'application peut provoquer des erreurs Robustesse L'immobilit : il est difficile d'extraire une partie de l'application pour la rutiliser dans une autre application.
Rutilisation
15
Gestion des volutions et des dpendances entre classes
Principe douverture/fermeture Open-Closed Principle (OCP) Touche pas mon code Principe de substitution de Liskov Liskov Substitution Principle (LSP) Les enfants doivent respecter le contrat
Principe dinversion des dpendances Dependency Inversion Principle (DIP)

Utiliser des Interfaces Principe de sparation des interfaces Interface Segregation Principle (ISP) Diviser les interfaces
16
Exemple : utilisation de la dlgation abstraite (OCP)

A gre les cas c1 et c2. Si un nouveau cas c3 doit tre gr, il faut modifier le code de A en consquence :
17
Lapplication de lOCP est un choix stratgique (OCP)
L'OCP est un principe incontournable lorsque l'on parle de flexibilit du code. Par contre, une erreur classique consisterait vouloir ouvrir/fermer toutes les
classes de l'application en vue d'ventuels changements.
Cela constitue une erreur dans la mesure o la mise en oeuvre de l'OCP impose une certaine complexit qui devient nfaste si la flexibilit recherche n'est pas rellement exploite.
Il convient donc d'identifier correctement les points d'ouverture/fermeture de l'application, en s'inspirant :

des besoins d'volutivit exprims par le client,
des besoins de flexibilit pressentis par les dveloppeurs,

des changements rpts constats au cours du dveloppement.
La mise en oeuvre de ce principe reste donc une affaire de bon sens.

18
Exemple : (OCP)
ID Personne nom : string age : int Personne(n : string, a : int) nom age
Appl1 Appl2
BD
Appl3 Avec adr
Rajouter un attribut Rajouter un constructeur Rajoute un paramtre au constructeur Faire une nouvelle classe PersonneAdr Rajouter une mthode getAdr mme ds Personne
19
Exemple : (OCP) Solution

Personne nom : string age : int Rend une chane vide: Appl3 peut alors utiliser des Personnes Personne(n : string, a : int) GetAdresse() : string
Appl1 Appl2
PersonneDomicilee adresse : string PersonneDomiciliee(n : string, a : int, adr : string) GetAdresse() : string SetAdresse(p : string) : void
Appl3
Jouer sur les mthodes plus tt que sur les attributs Les gains : 2 versions dans le mme excutable
pas besoin de faire de VNR (faites la quand mme)
20
Principes de substitution de LISkOV (LSP)

Pour prtendre l'hritage, une sous-classe doit tre conue de sorte que ses instances puissent se substituer des instances de la classe de base partout o cette classe de base est utilise. Hriter dune interface En insistant sur cette approche de l'hritage, le principe de substitution s'oppose une pratique rpandue dans laquelle l'hritage est mis en oeuvre pour factoriser du code entre plusieurs classes.
C0
<<Interface>> I0
C1
C2
C1
C2
21
Principes de substitution de LISkOV (LSP) : exemple

class Rectangle { int longueur, largeur; public: virtual void setValeur(int long, int larg) {longueur = long; largeur = larg; }; class Carre : public Rectangle { public: virtual void setValeur(int long, int larg) { if (long != larg) throw std::exception( long !=larg"); super.setValeur(long, larg); } }; void utiliserRectangle(int lng) { leRectangle.setValeur(lng, lng * 2); assert(leRectangle.getArea() == (length*length*2));
Carre +SetValeur(p1: int, p2: int) Rectangle +longueur: int +largeur: int +SetValeur(p1: int, p2: int)
Que se passe-t-il si le Rectangle est un carr?Hritage<>Composition
22
Principes dinversion des dpendances (DIP)

Dans la plupart des applications, les modules de haut niveau (ceux qui portent la logique fonctionnelle de l'application ou les aspects "mtier") sont construits directement sur les modules de bas niveau (par exemple les librairies graphiques ou de communication) :" Le passage l'abstrait est valoris"
IHM
IHM
ObjetMetier
IHM
<<interface>> IObjetMetier IObjetMetier
IHM
ObjetMetier
ObjetMetier
ObjetMetier
23
Principes dinversion des dpendances (DIP)
Cela parat naturel au premier abord mais pose en ralit deux problmes essentiels :
Les modules de haut niveau doivent tre modifis lorsque les modules de bas niveau sont modifis. Il n'est pas possible de rutiliser les modules de haut niveau indpendamment de ceux de bas niveau. En d'autres termes, il n'est pas
possible de rutiliser la logique d'une application en dehors du contexte

technique dans lequel elle a t dveloppe.
La relation de dpendance doit tre inverse :
les modules de bas niveau doivent se conformer des interfaces dfinies et utilises par les modules de haut niveau.
24
Labstraction comme technique dinversion des dpendances (DIP)

Considrons deux classes A et B, A utilisant B comme indiqu sur le schma cidessous :
Pour inverser la dpendance de A vers B, on introduit une classe d'interface I dont drive B comme suit :
25
Principes de sparation des interfaces (ISP)

Pollution d'interface par agrgation de services
On retrouve dans la plupart des designs quelques classes qui rendent plusieurs services simultanment, comme l'illustre le schma ci-dessous :
26

L'inconvnient de ce genre de cas est que tous les clients ont une visibilit sur tous les services rendus par la classe :
Chaque client voit une interface trop riche dont une partie ne l'intresse pas, Chaque client peut tre impact par des changements d'une interface qu'il n'utilise pas.
Solution : sparation des services de l'interface

Le principe de sparation des interfaces stipule que chaque client ne doit "voir" que les services qu'il utilise rellement
27
28
Techniques de sparation (ISP)

Il existe deux techniques principales de mise en pratique de l'ISP :
L'hritage multiple, Le Design Pattern "Adapter".
29
Sparation par hritage multiple (ISP)

Dans cette approche chaque service est reprsent par une classe d'interface dont drive la classe qui implmente les services. Les clients ne voient les services qu'au travers de ces classes d'interface comme le montre le schma suivant :
30
Sparation par adaptateur (ISP)

Lorsque l'hritage multiple n'est pas possible, les services peuvent tre reprsents par des classes d'adaptation :
31
Winston Royce. Managing the Development of Large Software Systems. 1970
Processus Objet
UP XP-Agile
32
UP: Caractristiques essentielles

UPRUPXUP
Caractristiques essentielles du processus unifi : - Le processus unifi est base de composants, -Le processus unifi utilise le langage UML (ensemble d'outils et de diagramme), - Le processus unifi est pilot par les cas dutilisation, -Centr sur larchitecture (plate-forme, performances, rutilisation, indpendante des UC, Y, ) - Itratif et incrmental.
33
UP & les modles UML (1)
34
UP & les modles UML (2)

Modle des cas dutilisation Modle danalyse Expose les cas dutilisation et leurs relations avec les utilisateurs Dtaille les cas dutilisation et procde une premire rpartition du comportement du systme entre divers objets Dfinit la structure statique du systme sous forme de sous systme, classes et interfaces ; Dfinit les cas dutilisation raliss sous forme de collaborations entre les sous systmes les classes et les interfaces Intgre les composants (code source) et la correspondance entre les classes et les composants Dcrit les cas de test vrifiant les cas dutilisation Dfinit les nuds physiques des ordinateurs et laffectation de ces composants sur ces nuds. Description de larchitecture (rutilisable)
35
Modle de conception
Modle dimplmentation Modle de test Modle de dploiement Modle d'architecture
UP & L'organisation matricielle
36
Processus Objet
XP-Agile Extrem programing La programmation extrme Les processus agiles
37
Pourquoi une nouvelle Mthode ?

Les approches classiques de dveloppement type "waterfall", bases sur la fameuse Squence spcification / conception / ralisation / validation, souffrent de problmes chroniques : Les spcifications sont dfinies au dbut du projet, alors qu'on en sait encore peu sur le sujet, Les spcifications diffrencient rarement ce qui est important de ce qui ne l'est pas, L'application se rigidifie progressivement en un produit "final" souvent difficile faire voluer et maintenir, Les activits sont compartimentes en fonction des spcialits des dveloppeurs, ce qui pose des problmes de rpartition des tches et limite la circulation des connaissances dans l'quipe.
38
Les mthodes agiles

Anne 80 : RAD (100 jours) Anne 90 : XP (Chrysler) et DSDM (Angleterre) (Dynamic Software Development Method) 2001 : Le manifeste Agile individus et interactions plutt que processus et outils dveloppement logiciel plutt que documentation exhaustive collaboration avec le client plutt que ngociation contractuelle ouverture au changement plutt que suivi dun plan rigide
39
Les valeurs d' XP (1)

Communication XP intgre rellement le client au projet pour qu'il dfinisse mieux ses besoins, arbitre les priorits et apporte ses connaissances mtier l'quipe. XP fait travailler tous les dveloppeurs ensemble et les fait participer toutes les activits du dveloppement, crant ainsi une relle dynamique d'quipe. XP rend accessible tous les intervenants l'ensemble des indicateurs d'avancement du projet. Feedback XP fournit des livraisons rgulires au client pour lui permettre d'affiner et de complter la dfinition de ses besoins partir de donnes concrtes. XP met en place des batteries de tests d'acceptation qui mesurent concrtement l'avancement des dveloppements. XP met en place des batteries de tests unitaires qui indiquent rapidement si le code fonctionne et qui dtectent instantanment toute rgression.
40
Les valeurs d' XP (2)

Simplicit XP s'assure que seules les fonctionnalits demandes par le client sont implmentes. XP maintient un design et un code toujours aussi simples que possible pour rester ouvert au changement et conserver une grande vitesse de dveloppement tout au long du projet. Courage XP donne au jour le jour une transparence maximale sur l'tat d'avancement rel du projet. XP s'attaque aux problmes ds qu'ils se prsentent, en autorisant des retours en arrire s'ils sont ncessaires.
41
Binme (1)
Binme Bien peru des programmeurs Garantit lhomognit du code, le respect des rgle de codage Responsabilit et connaissance collective du code Facilite la communication (moins de situation de blocage) Pousse bien faire (Motivation et satisfaction) Phase d'adaptation de 2 semaines Ne pas accepter ceux qui refusent Le code est de meilleur qualit (ils pensent + aux cas particuliers) Stand up meeting chaque soir Faire tourner les binmes 42 Rpartition des comptences
Binme (2)
Exploration dun problme (Spike - CrcCards) Nom des objets (bonne comprhension) Prendre le temps de bien le faire (Mtaphore local) Documenter le code Pas de documentation mais un code bien comment (Dclaration) Espace de travail Espace de dveloppement central Bureautique en priphrie Grande table de runion dans le bureau Grand crans pour le dveloppement Tout le monde se voit (mobilier spcifique?)
43
TU
Tests unitaires Aide la conception dtaill Systmatiquement avant le code (inhabituelle) Ne doit pas passer au dbut (Iconoclaste?) Ne pas dvelopper plus que ce qui est ncessaire pour le test Auto-vrifiant (18000 tests passs en 15 mn-tests passs de 15 mn 20 secondes) Tous les tests de tous les modules doivent passer sans erreur avant dintgrer le code Super aide la non rgression, au changement de conception et au remaniement Cela peut tre mis en uvre hors de XP
44
La Planification
La planification collective en dbut dincrment (Une journe) Incrment de trois semaines Lecture et explications des user stories (cas dutilisation) Grandes lignes de la conception Dfinition et valuation des tches valuation en temps idal + Load factor valuation en deux groupes. Le minimum est choisi si aucune difficult na t oublie.
45
Conditions dapplication
Il faut : Une quipe qui sentende bien et rduite (12 max) Dveloppement mono site Programmation par composants Que le client participe et adhre
Il ne faut pas: Une spcification complte et dtaille du futur systme Mesurer la qualit de la documentation au poids
46
Les principes de base

Seul le code source fait foi, il possde une odeur Limportant cest le programmeur Faire le plus simple possible Restructurer ds que ncessaire Pratiquer la programmation par paire Les spcifications sont des histoires dutilisateurs La planification est un jeu Livrer frquemment Tester encore, toujours et tout le temps tre courageux
47
histoires dutilisateurs
Une histoire est une unit de livraison Des descriptions rdiges par les utilisateurs (clients) Pour chaque histoire : le client donne : Priorit Tests dacceptation Les dveloppeurs : Estimation de la charge de la ralisation (lhistoire peut tre dcoupe en tches) RMQ : Une histoire est un trs gros use case
48
La planification est un jeu

XP tente de dsamorcer les conflits
Dfinition des itrations : Histoires avec les priorits Proposer des choix au client Un vrai dialogue Client Dveloppeur
49
tre courageux
Standup meeting Choisir des tches que lon ne sait pas faire Accepter dexpliquer aux autres ce que lon sait Sarrter de dvelopper pour faire du refactoring Accepter de ne pas tre responsable, alors quon est plus fort Ne pas avoir les yeux plus gros que le ventre
50
Droulement
Scrum
51
Processus Objet
Tests Refactoring
52
Test et Junit
Entreprise -lesEmployes: ArrayList = new ArrayList() +Embaucher(p: Personne) +Virer(p: Personne) +nbEmploye(): int +Faillite()
-lesEmployes
0..*
Personne -nom: String ~age: int <<create>>+Personne(n: String, a: int) +getAge(): int +setAge(age: int) +getNom(): String +setNom(nom: String) ~Afficher() ~Travailler()
53
Junit
54
Junit : Ecrire le test

package com.moi.test.junit; import junit.framework.TestCase; public class MaClasseTest extends TestCase { private MaClasse maClasse = null; public MaClasseTest(String arg0) { super(arg0); } public static void main(String[] args) { junit.swingui.TestRunner.run(MaClasseTest.class); } protected void setUp() throws Exception { super.setUp(); maClasse = new MaClasse(); } protected void tearDown() throws Exception { super.tearDown(); maClasse = null; } public void testAdditioner() { assertTrue(maClasse.additioner(2,2) == 4); } }
55
Junit : lancement du test
Regrouper les tests : Sur un projet ou un package Faire new JunitTestSuite (Other) Junit4
56
Tests : Les couches

Blabla
CTRL Objets mtier Serialisation
BD
String global
Les objets mtier offrent des interfaces pour les IHM (le CTRL) En analyse : Les trois axes d' une classe
57
Couverture de test
58
Le Refactoring :Principes (1)

Programmer au plus simple Faire du refactoring tout le temps (comme le mnage) Faire des itrations spciales Sassurer que : Les tests existent Ils sont OK Faire des petites choses Renommer Dcouper Dplacer
59
Le Refactoring :Principes (2)

Mettre en place des design patterns Composer des design patterns Accepter de " refactorer " le code des autres Remonter des interfaces Utiliser des Interfaces ou des classes abstraites Utiliser les outils de refactoring (Eclipse)
60
Le refactoring dans Eclipse (1)
Extract Method : Cre une nouvelle mthode encapsulant les lments slectionns, et remplace toutes les rfrences ces lments (mme ailleurs dans le code), par un appel vers cette mthode.
Rename : Renomme l'lment slectionn. Move : Dplace l'lment slectionn, par exemple enlever la classe du paquetage actuel, et la place dans un autre paquetage (voire un nouveau)
Change Method Signature : Modifie la signature de la mthode en cours, c'est--dire ses droits d'accs (public / private / protected / default). Peuvent galement tre modifis par cet assistant : le type du rsultat, l'ordre, le nom et le type des paramtres
et les dclarations d'exceptions.
Convert Local Variable to Field : Transforme une variable locale, dfinie dans une mthode, en champ de classe
61
Extract Local Variable : De la mme manire que Extract Method, cette fonction cre une nouvelle variable assigne l'expression slectionne.
Inline : C'est la fonction inverse de Extract Local Variable : elle rtablit l'expression assigne la variable, en lieu et place de la variable, qui disparat.
Particulirement utile si l'on se rend compte qu'une variable locale n'est utilise
qu'une fois, et que le programme n'est jamais assez optimis.
Push Down... Pull Up : Ces deux fonctions marchent dans le mme sens, mais avec des directions diffrentes : elles dplacent la slection respectivement vers la sous-classe ou la superclasse actuelle
Use Supertype Where Possible : Remplace les occurrences d'un type par l'un de ses supertypes, non sans avoir identifi auparavant tous les emplacements o
62
Extract Interface : l'instar des prcdentes fonctions de types Extract, celle-ci se charge de prendre les lments slectionnes et d'en tirer une classe disposant des mthodes de la classe en cours, et implmente cette interface sur la classe.
Encapsulate Field : Remplace toutes les rfrences un champ de classe, par des mthodes get et set pour ce champ.
Introduce Factory : Cre une nouvelle mthode de type Factory (voir plus loin),
en gnrant pour un constructeur donn la mthode statique approprie.
63
Use Supertype Where Possible : Remplace les occurrences d'un type par l'un de ses supertypes, non sans avoir identifi auparavant tous les emplacements o ce remplacement est possible. .
64
Refactoring : exercice(1)
Film +ENFANTS: int = 2 +NORMAL: int = 0 +NOUVEAUTE: int = 1 -titre: String -categorie: int <<create>>+Film(t: String, c: int) +getCategorie(): int +setCategorie(arg: int) +getTitre(): String Location -film: Film -duree: int 1 <<create>>+Location(movie: Film, d: int) +getDuree(): int +getFilm(): Film 0..*
Un film une catgorie (enf, norm, nouv un titre Une location concerne un film une dure
Cot de la location norm : 2 + 1.5 par jour au de la +main(args: String) <<create>>+Client(name: String) +addRental(arg: Location) du deuxime jour +getNom(): String +statement(): String nouv : 3 par jour enf : 1.5 + 1.5 par jour au de la du troisime jour Bonus : Chaque location donne un point, si une nouveaut est loue plu qu'un jour, alors un point supplmentaire. 65
Client Main_1 -nom: String -lesLocations: Vector = new Vector()
66
67
Refactoring : correction
Client -nom: String -lesLocations: Vector = new Vector() <<create>>+Client(name: String) +addRental(arg: Location) +getNom(): String +statement(): String Film +ENFANTS: int = 2 +NORMAL: int = 0 +NOUVEAUTE: int = 1 -titre: String -categorie: int <<create>>+Film(t: String, c: int) +getCategorie(): int +setCategorie(arg: int) +getTitre(): String
Location
-film: Film -duree: int <<create>>+Location(movie: Film, d: int) +getDuree(): int +getFilm(): Film
Main_1 +main(args: String)
+calculerPrix(): double +calculerBonus(): int
LocationEnfant <<create>>+LocationEnfant(f: Film, d: int) +calculerPrix(): double
LocationNormal <<create>>+LocationNormal(movie: Film, d: int) +calculerPrix(): double
LocationNouveaute <<create>>+LocationNouveaute(f: Film, d: int) +calculerPrix(): double
68
Les Design patterns

Le GoF Comportement Structure Cration
69
Les Design Patterns
Alexander writes: Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution. Problme: Comment allouer des objets en mmoire ? Contexte: un grand nombre d objets allous en mmoire virtuelle. Solution: identifier les objets amens collaborer frquemment un certain moment (ralisation d un service), et allouer ces objets dans une mme page mmoire.
Le choix des Design Patterns et de leur codage est un choix d architecture Les outils permettent d instancier les Design Patterns et de gnrer automatiquement le code 70
Prsentation des patrons de conception

Le patron de conception est lexpression dune problmatique rcurrente dun domaine et la dfinition dune solution gnrique ce problme. Le concept nest pas spcifique linformatique puisque son domaine dorigine est larchitecture. Les patrons de conception introduisent la rutilisation des expriences de conception logicielle Les problmes abords nous sont souvent familiers et les solutions proposes peuvent paratre simposer, mais cest lutilisation effective et au quotidien de ces prceptes qui constitue le vritable dfit et apporte une vritable plus-value.
71
Description des patrons de conception

Un patron de conception est une description textuelle, ventuellement enrichie de modles UML, dun problme de conception et du cur de sa solution. Cette description comporte typiquement les lments suivants : Un nom permettant de lidentifier Le problme et son contexte Les lments de solution et leurs relations Les bnfices et consquences induits Le catalogue le plus connu est celui de Erich Gamma qui recense dans son livre quelques 23 modles de conception oriente objet
72
Classification des patterns
Cration
Structure
Comportement
73
Les Design patterns de comportement (1)

State : un objet ragit selon son humeur
Stratgie : Faire une chose de diffrentes manires Template Methode : Faire une chose de diffrentes manires (avec une recette de base) Observer : certains sont intresses par ce que je fais, mais pas tout le temps Visiteur : Rajouter une responsabilit une classe avec des sous traitements identiques Memento : sauvegarder un objet Iterateur : Balayer une collection Chane de responsabilit : un lment est attendu par un grand nombre d'objets
74
Les Design patterns de comportement (2)

Commande : encapsule une requte dans un objet, et permet les files d'attentes, les journalisassions , et retours en arrire (undo). Mdiateur : dfinit un objet qui encapsule la manire dont un ensemble d'objets interagissent. Interprteur : dfinit un langage ainsi que sa grammaire, et fournit un interprteur pour utiliser la reprsentation du langage.
75
l Automate : contexte
Problme : Un mme objet doit rpondre une mme sollicitation de plusieurs manires diffrentes suivant son tat interne. Les oprations produisent des rsultats qui dpendent de ltat interne. Contexte : Fournir un approche systmatique d implantation des diagrammes d tats UML Solution : On va dissocier ltat de lobjet de lobjet lui-mme. Les tats
seront matrialiss par autant de classes, chacune spcialise dans la

gestion dun de ces tats. Lobjet na plus qu grer une instance reprsentant ltat courant et dlgue les appels de mthodes cette instance. Une classe parente abstraite ou une interface commune permettra lobjet de les manipuler dune faon homogne.
76
State : Prambule
Soit des stagiaires qui ragissent selon leur humeur : Si on leur demande de travailler: Si cest le matin, ils coutent. Si cest laprs midi, ils font la sieste. Si cest midi juste, ils grognent Si on leur demande de faire un exercice .
77
State : UML
Context
Etat
* +Op1(Context) +Op2(Context) +Op3(Context)
Client
+Op1() +Op2() +Op3() ~SetEtat(Etat)
Etat1 +Op1(Context) +Op2(Context)
Etat2 +Op2(Context) +Op3(Context)
Context Client +Op1() +Op2() +Op3() -SetEtat(Etat) *
Etat
+Op1(): Etat +Op2(): Etat +Op3(): Etat
Etat1 +Op1(): Etat +Op2(): Etat
78
State : Participants
Les classes et/ou objets participant dans ce pattern sont: Context Dfint la classe principale utilise par le client Garde une instance de la sous classe state pour dfinir ltat courant. Etat Dfinit linterface des diffrents tats. Concrete State Chaque sous classe implmente linterface du State conformment ce qui est faisable dans cet tat.
79
State : Exercice1- La banque
[ balance > 1000 ]
SilverState(0-1000)
do: Interet = 10%
GoldenState(>1000) do: Interet = 50% [ balance < 1000 ]
[ balance < 0 ] [ balance > 0 ] [ balance < 0 ]
RedState(<0) do: Interet = 0 do: Frais = 15
80
State : Exercice1- La banque
balance<0 => Pnalit de 15
Balance entre 0 et 1000 => Interet 10% Balance > 1000 => Interet 50%
balance<0 => Interet 0%
81
State : Exercice1
int main()
Silver
{ Account account("Jim"); account.Deposit(500.0); account.PayInterest (); account.Deposit(300.0); account.PayInterest (); account.Deposit(550.0); Gold account.PayInterest(); account.Withdraw(2000.00); Silverr account.PayInterest(); account.Withdraw(1100.00) ; account.Withdraw(1000); Red account.PayInterest(); account.Deposit(2000); Silver return 0; }
82
C1
State + Singleton
E1 C1 C2 C3 E3 C3 E2 C2 C2
83
State + Singleton Exo2

C1 E1 C1 C2 C3 E3 C3 E2 C2 C2
Objet o;
o.C1();o.C2();o.C3();o.C3(); Objet o1; o1.C1();o1.C3();o1.C2(); o1.C1();o1.C2();o1.C3(); o1.C1();o1.C3();
84
State : Remarques
Remarques :
- Les tats concrets peuvent possder une rfrence lobjet (possibilit pour l tat concret de manipuler les attributs de l objet) - Le changement dtat peut tre grer par lobjet lui-mme ou par les tats concrets.
Consquences :
- De nouveaux tats peuvent tre facilement ajouts - Les transitions dtat sont plus explicites - Si les tats concrets nont pas dtats internes (variables), alors ils peuvent tre partags (singleton)
Plus simple
85
Stratgie : contexte
On utilise Stratgie lorsque : De nombreuses classes associes ne diffrent que par leur comportement. Ce pattern permet de configurer une classe avec un comportement parmi plusieurs. On a besoin de plusieurs variantes d'algorithme. Un algorithme utilise des donnes que les clients ne doivent pas connatre.
86
Stratgie : UML
Context
+ContextInterface() +maStrategie
Strategie
+Algorithme()
ConcreteStrategieA +Algorithme()
ConcreteStrategieB +Algorithme()
Context Client +Op1() +Op2() +Op3() -SetEtat(Etat) *
Etat
+Op1(): Etat +Op2(): Etat +Op3(): Etat
87
Stratgie : Participants
Les classes et/ou objets participant dans ce pattern sont: Strategie (SortStrategy) Dclare une interface commune pour tous les algorithmes supports. ConcreteStrategie (QuickSort, ShellSort, MergeSort) Implmente un algorithme conformment linterface de la Strategie. Context (SortedList) Est configur avec un objet concreteStrategy Maintient une rfrence sur un objet Strategy Peut dfinir une interface qui permet la stratgie daccder ses donnes.
88
Stratgie : Exo
Renvoyer Celui qui gagne le plus Celui qui prend le plus de vacances Celui qui
Entreprise ~maStrategie: Strategie ~lesEmployes: ArrayList = new ArrayList() +setMaStrategie(maStrategie: Strategie) +Ajouter(e: Employe) +Rechercher(): Employe * Employe ~salaire: double ~vacances: int ~nom: String
public static void main(String[] args) { Entreprise e= new Entreprise(); <<create>>+Employe(nom: String, salaire: double, vacances: int) +getNom(): String Employe trouve; +getSalaire(): double e.Ajouter(new Employe ("Tchutchu" , 999999 , 0)); +getVacances(): int e.Ajouter(new Employe ("Duchmoll" , 1000 , 10)); e.Ajouter(new Employe ("Casta" , 10000 , 30)); e.setMaStrategie(new RechercherGrossesVacances()); trouve = e.Rechercher(); System.out.println ("Virer le paresseux : " + trouve.getNom()); e.setMaStrategie(new RechercherGrosSalaire()); trouve = e.Rechercher(); System.out.println ("Virer le plus cher : " + trouve.getNom()); }
Virer le paresseux : Casta Virer le plus cher : Tchutchu
89
Patron de mthode : principe

Cest du code (un algorithme cabl pour toutes les sous classes) qui est fait principalement par appel de mthodes virtuelles et abstraites. Ressemble un template C++ Mcanismes trs diffrents Plus souple Les traitements peuvent diverger dune sous classe lautre alors que cela est impossible avec les templates Plus simple Cest du code en avance sur les futures sous-classes Avantage : Dcoupe des mthodes en mthodes plus fines
90
Patron de mthode : Exemple

MiamMiam
RonRon Cest drle
Patron de mthode
vivre
TravaillerMatin(); If (age > 15) Dejeuner(); TravaillerMatin(); TravaillerApresMidi(); else Jouer(); Loisir(); . Dormir();
91
Patron de mthode
BlaBlater: BlaBla TravaillerMatin: TravaillerMatin: Personneb Ouvrir(); BlaBlater(); age : int TravaillerApresMidi: TravaillerApresMidi: Dejeuner() Fermer(); <<{abstract}>> TravaillerMatin() BlaBlater(); Loisir: <<{abstract}>> TravaillerApresMidi() Loisir: Loisir() Histoire grivoise <<{abstract}>> Dormir() BlaBlater
Jouer() <<abstract>> Vivre()
Chirurgien
Professeur TravaillerMatin() TravaillerApresMidi() Loisir() BlaBlater()
TravaillerMatin() TravaillerApresMidi() Loisir()
92
Patron de mthode
TravaillerMatin(); Dejeuner(); TravaillerApresMidi(); Loisir(); Dormir();
TravaillerMatin: Dormir(); TravaillerApresMidi: AllerANPE(); Loisir: Pleurer();
93
Patron de mthode : Exo : Impts

Dclaration : Revenu annuel-loyer mensuel-fortune-nombre denfants
Nouvelle loi de finance :

(Calcul sur le revenu annuel) Impts sur le revenu : Couple avec enfants : Frais : -20 % moins 1000 par enfant IR = reste * 2/12 Couple sans enfant : Frais : -20 % IR = reste * 3/12 Clibataire Frais : -10 % IR = reste * 4/12 Taxe dhabitation Couple avec enfants : Un loyer moins 50 par enfants Couple sans enfant : Deux loyers Clibataire Deux loyers + 1000 ISF Couple avec enfants : 20% de (ISF-300000) si > 300000 sinon 0 Couple sans enfant : 20% de (ISF-200000) si > 200000 sinon 0 Clibataire 20% de (ISF-80000) si > 100000 sinon 0 Tout le monde profite dun parachute (non golden) qui slve au max 50% des revenus. Un clibataire libral paye un surplus dimpt de 5000 indpendamment du parachute fiscal 94 TVA sociale augmente de 5 points
Patron de mthode : Exo : Impts
95
lObserver : le contexte
Problme : Dfinir une interdpendance de type (de classe) un plusieurs, de faon telle que, quand un objet change d'tat, tous ceux qui en dpendent en soit notifis pour assumer leur propre mise jour. Contexte : Ne pas prsumer de lidentit des objets intresss par lvnement (limitation du couplage). Ne pas prsumer du nombre des intresss Solution : Implantation dune interaction entre objets de type souscription-diffusion
96
lObserver : la solution
le Sujet : Dfinit un mcanisme gnral de gestion des objets en dpendance
Maintient la liste des Observeurs l aide des mthodes attach(Observer*) et detach(Observer *) Fournit le mcanisme permettant de prvenir les Observeurs lorsqu un changement d tat se produit
l Observeur : Dfinit l interface update() permettant d tre prvenu d un changement d tat le SujetConcret : Sous-classe de Sujet, gre son tat interne et invoque notify() lorsque son tat change les Observeurs Concrets : Sous-Classes d Observeur, implentent l interface update() en fonction de leur besoin
97
lObserver : UML
Rutilisable
<<Interface>> Sujet +list<Observer> lesObserveurs +add(Observer) +remove(Observer) +notify()
Observer
+UpDate()
Observer1 +UpDate() Observer2 +UpDate()
SujetConcret +state +getState(): state +setState(p): void
Rmq : souvent UpDate contient des paramtres (evt, le sujet, l'tat du sujet, )
98
l Observer : la dynamique
: Observer1 : qq add() add() setState() notify() UpDate() getState() : Observer2 : SujetConcret
UpDate() remove()
setState() notify() UpDate() getState()
99
Observer : Participants
Les classes et/ou objets participant dans ce pattern sont: Sujet (Stock) Connat les observateurs. Plusieurs observateurs peuvent observer un mme sujet. Cela peut tre dynamique. Offre un moyen dattacher et de dtacher les observateurs. SujetConcret (IBM) Cest lui qui contient linformation observable. Prvient les observateurs quand linformation change. Observer (IInvestor) Cest juste la dfinition de linterface. les Observeri (Investor) Garde une rfrence sur le Sujet concret implmente linterface de lobserver pour aller chercher linformation.
100
Observer : Java
import java.util.*;
Observable -changed: bool +addObserver(Observer) +deleteObserver(Observer) +countObservers(): int +deleteObservers() +notifyObservers() #setChanged() <<interface>> Observer +update(Observable p1, Object p2)
setChanged () {changed = true;} NotifyObservers() { if (changed) { for each observer update(); changed = false; }
101
Cela permet d'optimiser en n'appelant pas les observers chaque changement d'tat du sujet,mais seulement aprs un setChanged().
Observer : Java- Swing

Public class Exemple{ JFrame cadre; Dois-je le faire
Non
Public static main(){ Oui Exemple e = new Exemple(); e.go();} Public void go(){ cadre =new JFrame(); Jbutton b = new Jbutton ( Dois-je le faire ); b.AddActionListener(new Ange()); b.AddActionListener(new Demon()); .} } class Ange implements ActionListener { Public void ActionPerformed(ActionEvent e) {Print Non }} class Ange implements ActionListener { Public void ActionPerformed(ActionEvent e) {Print Oui }}
102
Observer : Exercice1
Observable
-changed: bool
+addObserver(Observer) +deleteObserver(Observer) +countObservers(): int +deleteObservers() +notifyObservers() #setChanged()
Observer
Meteo -temperature: int +setChanged() +calculer() +getTemperature(): int
Skieur +update(p1: Observable, p2: Object)
Nageur +update(p1: Observable, p2: Object)
Meteo m = new Meteo(); Nageur n = new Nageur(); Skieur s =new Skieur(); m.addObserver(n); m.addObserver(s); m.calculer(); ? m.setChanged(); m.calculer(); 8 m.setChanged(); m.calculer(); 12 m.setChanged(); m.calculer();
Main Meteo.Calculer met temprature entre 0 et 20. Skieur.update va en vacances si la temprature est < 10 +main(args: String) Nageur.update va en vacances si la temprature est >= 10
le skieur va a la montagne : 8 le nageur va a la mer : 12 103 le skieur va a la montagne : 6
Observer : Exercice2
104
Visitor
Rajouter une (ou plusieurs) mthode un objet (sans la rajouter) !!!! A utiliser quand une classe ne sait pas ce quelle veut et quelle risque de vouloir beaucoup de choses. La classe fait dj beaucoup de petites choses L'objet visit accepte le visiteur (Accept (Visitor v)) Il dit alors v de visiter (v.Visit()) v fait son travail
105
Visitor : UML
<<interface>> Element +Accept(Visiteur) <<interface>> Visiteur +Visit(Element)
ElementVisit +Operation1() +Operation2() +Accept(Visiteur v)
VisiteurConcret1
v1 : VisiteurConcret1 : qq
e : ElementVisit
+Visit(Element e)
<<create>> <<create>> Accept(v1): void
Accept(Visiteur v) {v.Visit(this);}
Visit (Element e) {cast e->ElementVisit e.OPeration1() + e.OPeration2();}
Visit(Element e): void a=Operation1() b=Operation2()
a+b()
106
Visiteur et lobjet Composite
Iterator iter =employees.iterator(); { Employee e; while (iter.hasNext()) { e =(Employee)iter.next(); e.Accept(visitor);} }
RMQ : Il est possible dexplorer lensemble dun composite avec un visiteur. Dans ce cas Employee et Employees ont tous les deux une mthode Accept et sont donc des Elements.
107
Visitor :exercice
public static void main(String[] args) { Employees e = new Employees(); e.Attach(new Clerk("Hank", 25000.0, 14)); e.Attach(new Director("Elly", 35000.0, 16)); e.Attach(new President("Sarko", 45000.0, 21)); e.Accept(new IncomeVisitor()); e.Accept(new VacationVisitor()); }
Une entreprise veut soit : augmenter les salaires de 10% donner 2 jours de vacances supplmentaires d'autres combinaisons TBD
108
Visitor :correction
Employees -employees: ArrayList = new ArrayList() +Attach(employee: Employee) +Detach(employee: Employee) +Accept(visitor: IVisitor) -name: String * -income: double -vacationDays: int <<create>>+Employee(name: String, income: double, vacationDays: int) +getIncome(): double +setIncome(income: double) +getName(): String +setName(name: String) +getVacationDays(): int +setVacationDays(vacationDays: int) +Accept(visitor: IVisitor) Employee
<<interface>> Element +Accept(visitor: IVisitor)
<<interface>> IVisitor ~Visit(element: Element)
Clerk <<create>>+Clerk()
Director <<create>>+Director()
President <<create>>+President()
IncomeVisitor +Visit(element: Element)
VacationVisitor +Visit(element: Element)
Main_1 +main(args: String)
109
Mmento : UML
UnDo-ReDo La classe surveiller-----La mmoire----Le programme client (main)
Client
Originator -state +SaveMemento(): Memento +RestoreMemento(m: Memento): void
Memento -state +GetState() +SetState()
1 -monMenento
Caretaker +SetMemento(p Memento) +GetMemento(): Memento
SetMemento(p ) {moMemento = p;} SaveMemento() {m = new Memento(); m.SetState(state); return m;} GetMemento() : Memento {return monMemento;}
RestoreMemento(m) {state = m.GetState();}
110
Mmento : Participants
Memento Stock ltat interne (tout ou partie) de lobjet Origine. Il se protge contre les accs provenant dautres objets que lOriginator. Les mementos ont en effet 2 interfaces. Le careTaker voit une interface simplifie, il peut seulement passer le memento dautres objets. Au contraire loriginator voit une large interface, qui lui permet daccder a tous les champs. Originator Cre un memento contenant une photo de lui mme un instant donn (sauvegarde). Utilise le memento en cas de restauration. Caretaker Est responsable de la gestion des sauvegardes-restauration Il ne regarde jamais le contenu interne du Memento
111
import java.util.*; // "Originator" class SalesProspect { private String name; private String phone; private double budget;
Mmento : Exemple(1)
class Memento { private String name; private String phone; private double budget; // Constructors public Memento( String name, String phone, double budget ) { this.name = name; this.phone = phone; this.budget = budget; } public String getName() { return name; } public void setName(String value) { name = value; } public String getPhone() { return phone; } public void setPhone (String value) { phone = value; } public double getBudget() { return budget; } public void setBudget (double value) { budget = value; } } // "Caretaker" class ProspectMemory { private Memento memento; public void setMemento (Memento value){ memento = value; } public Memento getMemento () { return memento; } } 112
public String getName() { return name; } public void setName(String value) { name = value; } public String getPhone() { return phone; } public void setPhone (String value) { phone = value; } public double getBudget() { return budget; } public void setBudget (double value) { budget = value; }
public Memento SaveMemento() {return (new Memento( name, phone, budget ));}
public void RestoreMemento( Memento memento ) { this.name = memento.getName(); this.phone = memento.getPhone(); this.budget = memento.getBudget(); } public void Afficher() { System.out.println( "Sales prospect ---- " ); System.out.println( "Name: " + this.name ); System.out.println( "Phone: " + this.phone ); System.out.println( "Budget:" + this.budget ); } }
Mmento : Exemple(2)
public class MementoApp { public static void main(String argv[]) { SalesProspect s = new SalesProspect(); s.setName ( "Landru"); s.setPhone ("08080808"); s.setBudget( 25000.0); s.Afficher(); // Store internal state ProspectMemory m = new ProspectMemory(); m.setMemento( s.SaveMemento()); // Continue changing originator s.setName( "Tintin"); s.setPhone( "33333333"); s.setBudget( 1.0); s.Afficher(); // Restore saved state s.RestoreMemento( m.getMemento() ); s.Afficher(); } }
113
Memento : UML-Dynamique
: Client : Caretaker : Originator : Memento <<create>> SaveMemento(): void <<create>> SetState(): void
rend le memento SetMemento(p Memento): void GetMemento(): void
RestoreMemento(m): void
GetState(): void mis a jour de l'tat()
114
LItrateur-Iterator : le contexte
Balayer des collections
<<interface>> Enumeration +hasMoreElements():boolean() +nextElement() :Object()
<<interface>> Iterator +hasNext(): boolean +next(): Object +remove()
Problme, pas d'iterateur pour les tableaux, mais on peut le dvelopper
115
Itrateur: UML
Aggregate
+CreateIterator(): Iterator
Iterator
Client +First(): Object +Next(): Object +IsDone(): boolean +CurrentItem(): Object
ConcreteAggregate +CreateIterator(): Iterator -maCollection -position
ConcreteIterator
~ConcreteIterator(ConcreteAggragate)
CreateIterator(): return new ConcreteIterator(this);
116
Iterateur : Participants
Les classes et/ou objets participant dans ce pattern sont: Iterator dfinit une interface pour accder et traverser les lments dune collection. ConcreteIterator (Iterator) implmente linterface Iterator. garde trace de la position courante dans la collection. Aggregate (AbstractCollection) dfinit une interface pour crer (obtenir) un objet Iterator. ConcreteAggregate (Collection) Implmente linterface de cration et rend une instance dun objet ConcreteIterator
117
Itrateur : remarques
Un itrateur est dit robuste, sil garantit que insertions et suppressions ninterfreront pas avec le parcours. Problme Multithread Des oprations supplmentaires peuvent tre utilises : SauteA, Prcdent Une classe ne doit avoir qu'une seule responsabilit (au sens large) sinon, il y a plus Jeu Personne Telephone de risques de +connecter() +setNom() +numeroter() +quitter() +setAdresse() +raccrocher() +bouger() +setNumeroTel() changement +parler() +feu() +enregistrer() +clignoter() +pause() +charger() Java 5 (generics)
For (Object o : Collection) { o.fqq();}
PaquetDeCartes +hasNext() +next() +remove() +ajouterCarte() +retirerCarte() +battre() Caddie +ajouter(object) +retirer(object) +payer() DistributeurDeBonbons +getNombre() +getEtat() +getPosition()
118
Itrateur & Composite

Itrateur interne On peut balayer un composite en utilisant l'opration prvue (exempleGetCout()). Partir de la racine et simplement appeler la mthode Itrateur externe Il faut l'crire Mise en uvre d'une pile Utiliser des iterator normaux pour les lments composs
119
Itrateur : Exercice
Reprendre l'ordinateur du Composite Mettre les diffrents lments dans des tableaux Faire un iterateur de tableau Faire un itrateur externe pour l'ensemble
120
Chane de Responsabilit
Polymorphisme et rcursivit Utiliser la pattern Chane de responsabilit quand vous voulez donner plus dun objet une chance de traiter une requte Lensemble des objets est construit dynamiquement Avantages : Dcouple lmetteur de la requte de ses rcepteurs Simplifie lobjet qui envoie la requte car, il na pas besoin de connatre la structure de la hirarchie utilise, ni de conserver des rfrences directes sur les membres. Permet dajouter, modifier , supprimer des responsabilits en changeant la hirarchie Exemples : Machine trier les pices Traitement des mails lettres de fan => PDG rclamations => Service juridique demandes de modification => R&D publicit => Poubelle
121
Chain of Resp : UML

Client
Handler
0..1
+HandleRequest() -successor
Deux temps : Configurer la hirarchie Faire des demandes

Gere la request si possible sinon successor.HandleRequest(); ConcreteHandler +HandleRequest()
: Client
Grouillot : ConcreteHandler
successor : ConcreteHandler
HandleRequest() [OK] [OK-NOK] [NOK] : HandleRequest()
122
Chain of Resp : Participants

Les classes et/ou objets participant dans ce pattern sont: Handler (Approver) dfinit une interface pour grer les requtes (optionnel) implmente le lien successeur ConcreteHandler (Director, VicePresident, President) Gre une requte si il en est responsable Peut accder son successeur Passe la requte son successeur si il ne peut pas la traiter Client (ChainApp) Provoque le premier appel de la requte vers un ConcreteHandler de la chane des successeurs.
123
Chain of Resp : Exo

M Prsident <100000 V Vice-prsident <25000 F Comit >=100000 U
Directeur <10000
Director grouillot = new Director(); VicePresident Sam = new VicePresident(); President Tammy = new President(); Grouillot.SetSuccessor(Sam); Sam.SetSuccessor(Tammy); Purchase p = new Purchase( 350.00, "Formation"); Grouillot.ProcessRequest(p); p = new Purchase( 24000, "Voiture"); Grouillot.ProcessRequest(p); p =new Purchase ( 99000, "Maison"); Grouillot.ProcessRequest(p); p = new Purchase( 122100.00, "Usine"); Grouillot.ProcessRequest(p);
124
Command
Faire faire qq chose un objet sans le connatre Commander qq chose sans connatre celui qui le fera Rduction du couplage Permet : les logs (historiques) les undo-redo (avec ou sans Memento) temporisation d'action mise en file d'attente contrle souvent utiliser avec un composite pour excuter plusieurs commandes (notion de macro commande)
125
Command : UML
Configurateur
Client
Utilisateur
Invoker
Command
+Execute()
Receiver +Action() -receiver
receiver.Action()
ConcreteCommand +Execute()
: Client
: ConcreteCommand
a : Receiver
: Command
: Invoker
<<create>> <<create>> SetReceiver(a) Execute Action(): void Execute(): void
126
Command : Participants
Les classes et/ou objets participant dans ce pattern sont: Command dfinit une interface pour faire faire qq chose (Execute) ConcreteCommand Connat celui qui fait qq chose (Receiver) Implmente la mthode Execute en faisant faire le travail au receiver. Receiver Fait le travail, il ne connat personne Client Connat la ou les commandes concrtes et les initialisent avec un receiver. Invoker Fait faire qq chose sans connatre ni les commandes concrtes ni 127 les receivers (seulement l'interface)
Command : Exo
Un architecte Chef de chantier Pltrier Maon Couvreur Couvreur vreux Faire les murs externes Faire les murs internes Faire le toit Faire des recettes Construire (client) Je (Invoker) Je (Receiver) Je Je (Receiver) Je (Receiver) Je (Receiver) Je (Action) (Action) (Action) (DeAction) (Command)
construis les murs ext construis le toit casse le toit construis le toit casse le toit construis le toit construis les murs int
128
Command : Correction
Architect +Planifier() ChefDeChantier -taches: ArrayList = new ArrayList() +Add(c: Construire) +Construire() <<interface>> Construire +ConstruireElement() +Recetter(): boolean
Je Je Je Je Je Je Je
construis les murs construis le toit casse le toit construis le toit casse le toit construis le toit construis les murs
Mur Toiture -m: Couvreur <<create>>+Toiture(m: Couvreur) +ConstruireElement() +Recetter(): boolean -m: Macon <<create>>+Mur(m: Macon) +ConstruireElement() +Recetter(): boolean
CouvreurVerreux -err: int = 3 +FaireToit() +Recette(): boolean
Couvreur +FaireToit() +Recette(): boolean
Macon +FaireMur() +Recette(): boolean
129
Interpreter : UML
Context
Client
AbstractExpression
+Interpret()
TerminalExpression
NonterminalExpression
130
Mediator : UML
Mediator
+mediator
Colleague
ConcreteMediator
menu
Controleur
bouton
liste textArea
Rmq :Faade-Observer
131
Les Design patterns

Le GoF Structure
Proxy : cacher la complexit d'un objet Dcorateur : Rajouter une responsabilit une classe sans changer l'in Adaptateur : Adapter un objet un autre Composite : permet de traiter une structure d'objets de manire uniform (Des feuilles et des nuds) Faade : Reprsenter, regrouper et diriger un ensemble d'objets Poids mouche : Partager de nombreux minis objets Pont : permet de diffrencier une abstraction de son implmentation, permettant chacune d'voluer indpendamment.
132
Proxy :le contexte
On utilise un proxy : pour rfrencer un objet par un moyen plus complexe qu'un "pointeu pour rajouter, modifier, supprimer des responsabilits un objet sans changer ni la structure interne, ni l'interface. Il existe plusieurs types de proxy : Proxy distant (RMI) Proxy virtuel pour le cas de chargement d'objet trs volumineux Proxy de protection Proxy de rfrence intelligente : Persistence Comptage de rfrence .
133
Proxy : UML
Client
Sujet +Operation1()
Proxy +Operation1() +Proxy(p: Sujet)
SujetReel +leSujet +Operation1()
Proxy.Operation1() { fait qqchose.. leSujet.Operation1();} Proxy.Proxy(Sujet param){ leSujet = param;}

134
Proxy : Participants
Les classes et/ou objets participant dans ce pattern sont: Proxy remplace lobjet rel et pointe vers celui-ci Operation1 fait le traitement suivant: Proxy distant : fabrique un message et l'envoie au Sujet rel via un skeleton. Le proxy s'appelle alors un stub. Proxy de protection : vrifie si l'appelant a les droits pour excuter l'opration, il l'accepte ou la refuse. On peut utiliser l'API InvocationHandler Proxy virtuel : exemple chargement d'une image. Le proxy lance le chargement de l'image et affiche le % de temps restant. Lorsque l'image est charge, alors il l'affiche. Proxy de rfrence intelligente : exemple smart pointer du 135 C++
RPC
Proxy Distant
DCOM
WEBSERVICE
RMI
CORBA
IDL Interface WSDL
Client
Sujet +Operation1()
SujetReel +Operation1()
Call
Proxy
RMIC
Call
Stub
+Operation1() +Proxy(p: Sujet)
skeleton
Send
136
Proxy Distant :RMI (1)
Utilisation de rmi ( import java.rmi.* ) Crer une interface distante: public interface Sujet extends Remote public void Operation1() throws RemoteException; s'assurer que les paramtres et valeur de retour sont serialisable Crer une implmentation distante SujetReel public class SujetReel extends UnicastRemoteObject implements S Ecrire un constructeur sans argument,avec excpt public SujetReel() throws RemoteException vv Enregistrer le service try { SujetReel leSujetReel = new SujetReel(); naming.rebind ( "BonjourDeLoin" , leSujetReel); }catch (Exception e) {}
137
Proxy Distant :RMI (2)

Gnrer le stub (proxy) et le skeleton lancer rmic sur le fichier SujetReel.java rmic SujetReel Excuter rmiregistry (outil pour l'enregistrement) en tapant simplement dans une fentre dos rmiregistry Dmarrer le service en tapant : java SujetReel Le client peut alors utiliser le service Sujet monSujet = (Sujet) Naming.Lookup ("rmi://127.0.0.1/ BonjourDeLoin"); monSujeT.Operation1();
Proxy Distant :Exercice

138
Proxy de protection :exercice (1)

Employe -nom: String -salaire: double -titre: String <<create>>+Employe(nom: String, salaire: double, titre: String) +Travailler() +Afficher() +getNom(): String +getSalaire(): double +setSalaire(salaire: double)
Main +main(args: String)
<<interface>> IEmploye +Travailler() +Afficher() +getNom() +getSalaire() +setSalaire()
ProxyEmploye -employe: Employe <<create>>+ProxyEmploye(employe: Employe) +Afficher() +getNom(): String +getSalaire(): double +setSalaire(salaire: double) +Travailler()
ProxyPatron -employe: Employe <<create>>+ProxyPatron(employe: Employe) +Afficher() +getNom(): String +getSalaire(): double +setSalaire(salaire: double) +Travailler()
139
Proxy de protection :exercice (2)
140
Proxy de protection avec InvocationHandler

<<interface>> BeanPersonne ~getNom(): String ~getSexe(): String ~getInterets(): String ~getSexyOuNon(): int ~setNom(nom: String) ~setSexe(sexe: String) ~setInterets(interets: String) ~setSexyOuNon(note: int)
Moi mme
getNom() getSexe() getInterest() getSexyOuNon() SetNom(String) setSexe(String) setInterest(String) setSexyOuNon(int)
Les autres
getNom() getSexe() getInterest() getSexyOuNon() SetNom(String) setSexe(String) setInterest(String) setSexyOuNon(int)
Rmq : setSexyOuNon () fait la moyenne des notes obtenues 141
Proxy de protection avec InvocationHandler

<<interface>> BeanPersonne ~getNom(): String ~getSexe(): String ~getInterets(): String ~getSexyOuNon(): int ~setNom(nom: String) ~setSexe(sexe: String) ~setInterets(interets: String) ~setSexyOuNon(note: int) TestRencontres ~basedonnees: Hashtable = new Hashtable() <<create>>+TestRencontres() +main(args: String) +tester() ~getProxyProprietaire(personne: BeanPersonne): BeanPersonne ~getProxyNonProprietaire(personne: BeanPersonne): BeanPersonne ~getPersonneDepuisBD(nom: String): BeanPersonne ~initialiserBD()
InvocationHandlerNonProprietaire BeanPersonneImpl ~nom: String ~sexe: String ~interets: String ~note: int ~nombreDeNotes: int = 0 +getNom(): String +getSexe(): String +getInterets(): String +getSexyOuNon(): int +setNom(nom: String) +setSexe(sexe: String) +setInterets(interets: String) +setSexyOuNon(note: int) ~personne: BeanPersonne <<create>>+InvocationHandlerNonProprietaire(personne: BeanPersonne) +invoke(proxy: Object, method: Method, args: Object): Object
java.lang.reflect.InvocationHandler
InvocationHandlerProprietaire ~personne: BeanPersonne <<create>>+InvocationHandlerProprietaire(personne: BeanPersonne) +invoke(proxy: Object, method: Method, args: Object): Object
142
Mthode invoke de non Propritaire

InvocationHandlerNonProprietaire public Object invoke(Object proxy, Method method, Object[] args) throws IllegalAccessException { try { if (method.getName().startsWith("get")) { return method.invoke(personne, args); } else if (method.getName().equals("setSexyOuNon")) { return method.invoke(personne, args);} else if (method.getName().startsWith("set")) { throw new IllegalAccessException(); } } catch (InvocationTargetException e) { e.printStackTrace();}
143
Mthode invoke de Propritaire

InvocationHandlerProprietaire
public Object invoke(Object proxy, Method method, Object[] args) throws IllegalAccessException { try { if (method.getName().startsWith("get")) { return method.invoke(personne, args); } else if (method.getName().equals("setSexyOuNon")) { throw new IllegalAccessException();} else if (method.getName().startsWith("set")) { return method.invoke(personne, args);} } catch (InvocationTargetException e) {e.printStackTrac return null; }
144
Proxy invocationHandler :Exercice(1)
Rmq basedonnees est une Hashtable ---------------------------------------------Passage difficile :
145
Proxy invocationHandler :Exercice(2)
146
Decorator : Prsentation
Problme : nombreux hritages
Solution : Hritage hritage + agrgation (poupe russe)

147
Decorator :Le problme(1)

Nous allons revoir la faon dont on abuse gnralement de lhritage et vous allez apprendre comment dcorer vos classes au moment de lexcution en utilisant une forme de composition. Pourquoi? Une fois que vous connatrez les techniques de dcoration, vous pourrez affecter vos objets (ou ceux des autres) de nouvelles responsabilits sans modifier le code des classes sous-jacentes.
Un Deca avec du lait et du citron
RMQ :Le principe dOuverture (nhsitez pas tendre nos classes) et de Fermeture (Pas touche mon code)
148
Decorator :Le problme(2)

Ecrire les mthodes Boisson::Cout et Colombia::Cout
Boisson.Cout() { If GetLait() then cout += coutDuLait If GetVanille() then cout += coutVanille . Return cout; } Colombia::Cout () { Return 25+ super.Cout() }
Que se passe-t-il si on rajoute la crme Chantilly? Il faut modifier Boisson.Cout --- Pas touche mon code
149
Decorator : UML
ComposantConcret.Operation : fin de la chane Component
+Operation()
-monComposant 1
Decorateur.Operation() : monComposant.Operation
ComposantConcret +Operation() +ComposantConcret()
Decorateur
+Operation() +Decorateur(Component)
Decorateuri.Operation() fait qq chose super.Operation(
Decorateur1 +Operation() +Decorateur1(Component)
Decorateur2 +Operation() +Decorateur2(Component)
Cela revient rajouter une responsabilit une classe mais sans en changer l'interface. Comparer avec le composite
150
Decorator : la solution construction

Fabrication de l'objet : Boisson b= new Deca(); b = new Lait(b); b = new Citron (b); b = new Citron(new Lait(new Deca())); De l'extrieure, on ne voit que le citron.
+Operation()
La boisson
Component +Operation()
-monComposant 1
Les ingrdients
Decorateur
+Operation()
ComposantConcret
Deca
Decorateur1 +Operation() Decorateur2 +Operation()
Citron
Lait

151
Decorator : la solution
Calcul du cot de la boisson : citron = 0.2(Fait qq chose) Component +super.Operation +Operation() monComposant.Operation lait = 0.3 (Fait qq chose) +super.Operation ComposantConcret monComposant.Operation +Operation() Deca = 0.5
Deca La boisson
-monComposant 1
Les ingrdients
Decorateur
+Operation()
Au retour Total = 1
Decorateur1 +Operation()
Decorateur2 +Operation()
Citron
Lait

152
Decorator : Participants
Les classes et/ou objets participant dans ce pattern sont: Component (Boisson) Dfinit linterface pour les objets qui peuvent avoir des responsabilits ajoutes dynamiquement. ConcreteComponent (deca) Dfinit un objet auquel on peut rajouter des responsabilit s. Decorator (Ingredient) Maintient une rfrence sur le component et dfinie une interface conforme conforme celle du component. ConcreteDecorator (citron) Ajoute les responsabilits au composant.
153
Decorator : Exemple
On utilise lhritage entre Ingrdient et boisson par Snobisme Boisson::Cout est abstraite Colombia::Cout return 25 (le cot du Colombia sans ingrdient Lait::Cout return le cout du Lait(10) + Le cot de maBoisson
Utilisation : Boisson b1 = new Colombia() b1.cout() => 25
Colombi a
Boisson b2 =new Colombia() b2 = new Lait(b2); b2.cout()=> 25 + 10

b2 = new Citron(b2); .. Citron
Lait
Colo mbia
Que se passe-t-il si on rajoute la crme Chantilly? Il faut rajouter la classe Chantilly
Lait
Colombi a
154
Decorator : Un mauvais exemple(1)
155
Decorator : un mauvais exemple (2)
156
Decorator : Exercice
Soldat +bagarrer(): int +getVie(): int +setVie(p: int)
+component
SoldatNu +vie: int +bagarrer(): int +getVie(): int +setVie(p: int) +SoldatNu()
Decorator +getVie(): int +setVie(p: int) +bagarrer(): int
SoldatAvecEpee +bagarrer(): int +SoldatAvecEpee(p: Soldat) SoldatPatient +bagarrer(): int +SoldatPatient(p: Soldat)
SoldatAvecFusil +bagarrer(): int +SoldatAvecFusil(p: Soldat)
157
l Adaptateur : le contexte
Objectif :L'adaptateur met en conformit l'interface d'une classe au besoin d'une classe cliente. L'adaptateur permet des classes de collaborer, qui n'auraient pu le faire du fait d'interfaces incompatible. Contexte : Ce pattern est particulirement adapt lorsque les conditions suivantes sont remplies :
On veut utiliser une classe existante dont l'interface ne concide pas avec celle escompte On souhaite crer une classe qui puisse tre accde par des interfaces diverses Rcupration de vieilleries Faade
158
l Adaptateur : Uml et Exemple

Client
Cible +fqq()
Adapteur.fqq()= Adapt.fac()
Adapteur +fqq()
Adapt +fac()
<<interface>> Travailleur +Travailler()
Chomeur +ChercherDuTravail()
Dentiste +Travailler()
Boulanger +Travailler()
SarkoChomeur +Travailler()
Chomeur +monChomeur +ChercherDuTravail()
monChomeur.ChercherDuTravail
super.ChercherDuTravail
159
L'adaptateur : Participants
Les classes et/ou objets participant dans ce pattern sont: Cible Dfinit ce qui est appel par le client Adapteur Fait le lien entre ce que veut le client et ce qui existe vraiment Adapt Cest ce qui existe vraiment (rcupration) Client Ne connat que linterface de la cible.
160
L'adaptateur : Exercice
Cancaneur
+Cancaner()
Cacardeur +Cacarder()
Canard
CanardPlastique Oie +Cacarder()
Leurre
Canard.Cancaner "Coincoin" Leurre.Cancaner "Silence" CanardPlastique "Pchiff" Oie.Cacarder " CoincoinCoincoin " Pb : Faire cancaner une troupe de Cancaneur contenant des oies
161
Composite : Le contexte & UML

On utilise le Composite lorsque on veut : Reprsenter une hirarchie d'objets Ignorer la diffrence entre un composant simple et un composant en contenant d'autres (interface uniforme)
Client
Component
+Operation() * +lesEnfants
Operation() pour chaque enfant : Faire Operation() puis faire qq chose si besoin pour le composite Leaf +Operation()
Composite +Operation() +Add(p: Component) +Remove(p: Component) +GetChild(index: int): Component
Comparer avec le dcorateur

162
Composite : Participants
Component (Equipement) Dclare linterface pour les objets de la composition. Leaf (Peripherique) Reprsente les objets feuilles (sans enfants) de la composition. Dfinit le comportement de ces objets. Composite (Container) Dfinit le comportement des objets ayant des enfants. Range, stocke les composants enfants Client (pg main) Manipule les objets comme un seul en sappuyant sur linterface du component. Utilisation : Fabriquer l'objet (Configurer) Le client peut alors appeler Operation () sur l'objet global. L'objet global est un composite (ou une feuille) particulier qui prmet de retrouver l'ensemble du composite 163
Composite : Exercice
Carte mre
Ordi IBM
Tour
DVD HD
Carte mre
Pentium Ventilo // Configuration Peripherique p1 = new Peripherique ("DVD", 100,8); Peripherique p2 = new Peripherique ("Disque Dur", 1000,9); Peripherique p3 = new Peripherique ("Modem ADSL", 1,8); Peripherique p4 = new Peripherique ("Pentium", 3500 ,386); Peripherique p5 = new Peripherique ("Ventilo ", 150,15); Container carteMere = new Container ("Carte mre"); carteMere.Ajouter(p4);carteMere.Ajouter(p5); TourDeLuxe tour = new TourDeLuxe ("tour",100); tour.Ajouter(p1);tour.Ajouter(p2);tour.Ajouter(carteMere); Container ordi = new Container ("IBM"); Ordi.Ajouter (tour);ordi.Ajouter (p3); // Utilisation System.out.println( "le prix total est de : " + ordi.GetPrix() );
164
Modem Adsl
Composite Leaf
Composite : Solution
165
Faade : UML
166
Problme : La conception objet implique la dcomposition de chaque systme complexe en collection dobjets collaborant. On veut limiter le couplage des utilisateurs du systme avec les lments de cette dcomposition. On veut garder la possibilit pour certains client de manipuler lintrieur du systme. Solution : On cr un nouvel objet servant de faade un type dutilisateur donn et lui offrant des services de haut niveau.
La Faade : le contexte
167
La Faade : les bnfices

Consquences :
Dcouplage dune partie des clients avec le systme considr. Rduction du nombre de classes (complexit) prendre en compte pour ce client Rduction des dpendances la compilation Certains langages (C++ avec les NameSpaces, java avec les packages) permettent de cacher une partie des classes dun sous-systme. -> Encapsulation au niveau des systmes
168
Faade : Participants
Les classes et/ou objets participant dans ce pattern sont: Faade (Prt) Connat les classes du sous systme qui sont responsables de chaque requte. Transmet les requtes aux classes adquat. Subsystem classes (VerifApport, VerifSalaire, VerifCaution) Implmentent les fonctionnalits du sous systme. Ne connaissent pas la faade Exemple : Transformation d'une liste en pile
169
Faade : Exo
VerifApport ~apport: double ~pret: double <<create>>+VerifApport(apport: double, pret: double) +Verif(): boolean
Apport est au moins de 10% du prt Prt <= 250 fois le salaire Caution >= 50% du prt
true Refus false Refus Refus Refus false
VerifSalaire ~salaire: double ~pret: double <<create>>+VerifSalaire(salaire: double, pret: double) +Verif(): boolean
caution trop faible salaire trop faible caution trop faible apport trop faible
VerifCaution ~caution: double ~pret: double <<create>>+VerifCaution(caution: double, pret: double) +Verif(): boolean
Facade f =new Facade(); System.out.println(f.AccepterPret(100000,1000,20000,55000)); System.out.println(f.AccepterPret(200000,1000,20000,55000)); System.out.println(f.AccepterPret(300000,1000,20000,55000));
Prt, salaire, apport, caution
170
Flyweight : Poids mouche :UML

FabriqueDePoidsMouche +GetFlyweight(key) +lesPoids PoidsMouche * +Operation()
PoidsMoucheConcret
PoidsMouchePartag
Client
Utilisation : Exemple :
beaucoup de petits objets se partager plusieurs. les caractres d'un document PluriGleton
171
Poids mouche : Exemple : une fort

Arbre -x: int -y: int +Afficher(): void
: Arbre : Arbre
: Arbre
: Arbre
: Arbre
Avantages : Rduit le nb d'instances Economise la mmoire Rmq :tous les arbres doivent tre grs de la mme manire
GestionnaireArbre +TableauXY +Afficher(): void
<<singleton>> ArbrePoidsMouche +Afficher(x: int, y: int): void
172
Bridge : UML
Rmq : ressemble au state

173
#include <iostream> using namespace std;
Bridge : Exemple
// .h class Implementor; class Abstraction { protected :Implementor *implementor; public : void SetImplementor(Implementor *value); virtual void Operation();} ;
class Implementor { public : virtual void Operation()=0; } ; class RefinedAbstraction : public Abstraction { public :void Operation();}; class ConcreteImplementorA : public Implementor { public : void Operation() ; } ; class ConcreteImplementorB : public Implementor { public : void Operation() ;}; int main() { Abstraction *ab = new RefinedAbstraction(); ab->SetImplementor( new ConcreteImplementorA()); ab->Operation(); ab->SetImplementor(new ConcreteImplementorB()); ab->Operation(); }
// .cpp void Abstraction::SetImplementor(Implementor *value) {implementor = value;} void Abstraction::Operation() { implementor->Operation(); } void RefinedAbstraction::Operation(){ implementor->Operation(); } void ConcreteImplementorA::Operation(){cout << "OperationA" << endl;} void ConcreteImplementorB::Operation(){ cout << "OperationB" << endl;}
174
Les Design patterns

Le GoF Cration
Singleton : un et un seul objet visible par tous Fabrication : crer un objet en fonction d'un paramtre Fabrique abstraite : crer une famille d'objets tous cohrents Monteur : construire un objet en diffrentes tapes Prototype : permet de spcifier le type d'objets crer en utilisant une instance prototype. Le prototype sera copi pour crer les nouveaux objets.
175
Le singleton
Problme : Une classe ncessite de ntre instancie quune seule fois dans une application Contexte : Cette instance unique est utilisable plusieurs endroits dans l application. Solution : On va confier la classe elle-mme la responsabilit dassurer lunicit de son instance.
176
Le singleton uml
177
Amlioration du singleton
L'usine singleton : Remplacer singletons par singleton
Rmq : En C++, mettre en private le constructeur de copie et l'oprate d'affectation
Rmq : En multi thread, utiliser un mutex ou synchronized.
178
Fabrication : Prsentation
Le problme : If cas1 alors return new c1(); Rgle POO : If cas2 alors return new c2(); Remplacer le switch par le polymorphism If cas3 alors return new c3();
Problme de dpendance, ce sous programme dpend de c1,c2,c3. Et ce problme arrive chaque fois que l'on veut crer un des ces obje C'est du code Beurgh!
La fabrication va garder et prendre en charge ce code Beurgh, au moin Il sera un seul endroit.
Fabrication : Garder le switch ce qui vitera de faire des New (et des dpendanc
179
Fabrication : Problme de dpendance

SousProgramme
Fabrication
C1
C2
C3
<<interface>> C
C1
C2
C3
La fabrication va permettre l'inversion des dpendances on va encapsuler la cration des objets dans une fabrique on peut crer plusieurs objets, mais ils sont indpendants les uns des autres
180
Fabrication : exemple les pizzerias(1)

Pizza
~nom: String ~pate: String ~sauce: String ~garnitures: ArrayList = new ArrayList() ~preparer() ~cuire() ~couper() ~emballer() +getNom(): String +toString(): String
Pizzeria ~creerPizza(item: String): Pizza +commanderPizza(type: String): Pizza
FabriqueDePizzasBrest ~creerPizza(item: String): Pizza
FabriqueDePizzasStrasbourg ~creerPizza(item: String): Pizza
L'usine
PizzaVegetarienneStyleStrasbourg <<create>>+PizzaVegetarienneStyleStrasbourg() ~couper() PizzaPoivronsStyleStrasbourg <<create>>+PizzaPoivronsStyleStrasbourg() ~couper()
PizzaVegetarienneStyleBrest <<create>>+PizzaVegetarienneStyleBrest()
TestPizzeria +main(args: String)
Les produits
181
Fabrication : exemple les pizzerias(2)

celleDeBrest : Pizzeria
[A]
: qq
brest-fromage : Pizza
commanderPizza(type: String): pizza
[B]
preparer(): void cuire(): void couper(): void emballer(): void
creerPizza(item: String): pizza
Pizza creerPizza(String item) if (item.equals("fromage")) { return new PizzaFromageStyleBrest();} else if
qq
Pizzeria fabriqueBrest = new FabriqueDePizzasBrest(); [A] Pizza pizza = fabriqueBrest.commanderPizza( "fromage" ); [B] System.out.println("Luc a command une " + pizza.getNom() + 182 "\n"
Fabrication : le Design pattern

Client
Createur Produit +fqq() +Fabrication(type: String): Produit +uneOperation()
ProduitConcret1 +fqq() CreateurConcret +Fabrication(type: String): Produit
ProduitConcret2 +fqq()
183
Fabrication : Participants
Les classes et/ou objets participant dans ce pattern sont: Produit (Page) Dfinie linterface des objets crs par la fabrication (Afficher) ProduitConcreti (Introduction,Plan,Conclusion,Dev) implementent linterface du produit (CreatePages) Createur (Document) Dclare la mthode "Fabrication(String) : Produit" qui rend un objet de type Produit. CreateurConcret (Report, Resume) Surcharge la mthode Fabrication pour rendre une instance du produit concret. C'est le code Beurgh!!! Rmq :la mthode peut ne pas avoir de paramtre, dans ce cas le code n'est pas beurgh.
184
Fabrication exercice
Le produit
<<interface>> Page +Afficher(): void Client
Fabrique
<<interface>> Fabrique +CreerPage(String: type): Page
Conclusion +Afficher(): void Introduction +Afficher(): void FabriqueConcrete +CreerPage(String: type): Page
FabriquePage fab = new FabriquePage(); Page i = fab.CreatePage("Intro"); i.Afficher(); i=fab.CreatePage("Conclusion"); i.Afficher();
185
Fabrication Abstraite : motivation

Application
IHM Motif IHM windows IHM Motif Application IHM IHM windows
L application utilise IHM sans savoir si il s agit de Motif ou bien de Windows
186
Fabrication Abstraite : Structure

Application
<<instancie>>
187
Fabrication Abstraite : Constituants

FabriqueAbstraite (Facultative)
Dclare une interface contenant les oprations de cration d objets produits abstraits Fabrique concrte Implmente les oprations de cration d objets produits concrets Produit Abstrait (Facultatif) Dclare une interface pour un type d objet produit Produit concret Dfinit un objet produit qui doit tre cre par la fabrication concrte correspondante Implmente l interface de ProduitAbstrait Application nutilise que les interfaces dclares par les classes FabriqueAbstraite et ProduitAbstrait
188
Fabrique Abstraite : Avantages et inconvnients

Isoler les classes concrtes Faciliter la substitution d une famille de produits Favoriser le maintien de la cohrence entre les objets Grer de nouveaux types de produits est complexe Ne facilite pas la lisibilit
FabriqueAbstraite CreerProduitA() CreerProduitB()
189
Builder-Monteur
On utilise le buider lorsque : L'algorithme pour crer un objet doit tre indpendant des parties qui le composent et de la faon de les assembler. Le processus de construction permet diffrentes reprsentations de l'objet construit. Rmq : Le monteur (Builder) est utilis pour construire diffrentes sortes dobjets selon une certaine mthodologie (tapes par tapes). Chaque tape dpend du type de lobjet, mais la succession des tapes en est indpendante. (comparer avec le patron de mthode)
190
Builder : UML
Director +Construct(Builder) +builder
Builder
+BuildPart1() +BuildPart2()
BuildPart1() BuildPart2(); GetResult(); ConcreteBuilder +BuildPart1() +BuildPart2() +GetResultt(): Product Product +list<Parties> leProduct
: Director : qq <<create>>
b1 : ConcreteBuilder
Construct(Builder): void BuildPart1(): void BuildPart2(): void GetResultt(): void
191
Builder : Participants
Les classes et/ou objets participant dans ce pattern sont:
Builder (VehicleBuilder) Spcifie une interface pour identifier les tapes de la cration dun produit. ConcreteBuilder (MotorCycleBuilder, CarBuilder, ScooterBuilder) Construit et assemble les diffrentes parties dun objet en implmentant linterface du Builder. Dfinit le produit final et permet de le retrouver. Director (Shop) Cest le client (celui qui utilise le builder). Product (Vehicle) Reprsente le ou les produits fabriqus
192
Builder : Exemple
Director +Construct(Builder)
Builder
+builder +BuildPart1() +BuildPart2() +GetResult(): Product1
Product ~leProduit: ArrayList = new ArrayList() +add(s: String) +show()
ConcreteBuilder2 -leProduit: Product1 <<create>>+ConcreteBuilder2() +buildPartA() +buildPartB() +getResult(): Product1
ConcreteBuilder1 -leProduit: Product1 <<create>>+ConcreteBuilder1() +buildPartA() +buildPartB() +getResult(): Product1
voici voici voici voici
la la la la
partie partie partie partie
A B A B
du du du du
produit1 produit1 produit2 193 produit2
Builder : Exo
void main() { Shop shop = new Shop(); VehicleBuilder b2 = new CarBuilder(); VehicleBuilder b3 = new MotorCycleBuilder(); shop.Construct(b2); b2.GetVehicle().Show(); shop.Construct(b3); b3.GetVehicle().Show(); }
Vehicule type : String moteur : String #vehicule roue : String porte : String 1 Show() : void
VehiculeBuilder GetVehicule() : Vehicule BuildMoteur() : void BuildRoue() : void BuildPorte() : void Shop Construire(p : VehiculeBuilder) : void
MotoBuilder BuildMoteur() : void BuildRoue() : void BuildPorte() : void MotoBuilder()
VoitureBuilder BuildMoteur() : void BuildRoue() : void BuildPorte() : void VoiturBuilder()
194
Prototype
Masque au client les complexits de la cration de nouvelles instances (new, clone, deserialisation, ) Permet au client de gnrer des objets dont le type nest pas connu. Dans certaines circonstances, la copie dun objet peut tre plus efficace que la cration dun objet (memberWiseClone du c#)
195
Prototype : Participants
Les classes et/ou objets participant dans ce pattern sont: Prototype Dclare une interface pour se cloner ConcretePrototype Implmente une opration pour se cloner Client Cr un nouvel objet en demandant au prototype de se cloner.
196
DP : Exercice gnral(1)
Les stagiaires ont un nom, un sexe et une catgorie (TM, M, Moyen, B , TB). Ils font des exos qui sont russis en fonction de leur tat (TM =4-10, M=5-10, B=10-15, TB=15-20,Moyen =11) Le prof note alatoirement (presque) les exos mais favorise les filles. (note en fonction de ltat, plus ou moins un nombre compris entre 10 et + 8, rajouter 2 points pour les filles (sauf pour les trs bonnes), la note finale est comprise entre 0-20. Quand un lve obtient une note < 7 son tat se dgrade, alors que si il obtient une note > 13 son tat samliore. Le chef vire celui ou celle qui a la plus mauvaise note chaque exercice. Bill Gates dbauche 2 fois le ou la meilleure, tandis que Google nen dbauche quun ou quune. Dautres personnes, entreprises ou organismes quelconques pourront bientt s intresser aux stagiaires. Singleton Toutes les notes sont sauvegardes pour chaque lve.
State
Observer
Strategie Template methode memento
197
198
Appelant +cancaner() Cancaneur CanardEnPlastique +cancaner() Leurre Colvert +cancaner() +cancaner() Mandarin +cancaner() SimulateurDeCanards +main(args: String) ~simuler() ~simuler(canard: Cancaneur)
Adaptateur Decorateur
Fabrique abstraite
Oie
Composite
+cacarder() Observer Traiter le cas des oies Compter les coinscoins Comment tre sr de compter tout le monde ? Faire cancaner toute une troupe Observer de temps en temps et en temps rel le couac de chaque canard
199
Autres Patterns
Les classes d'analyse Le raii
200
Les classes d'analyse

uc1
Les trois axes d'une classe : Boundery - Frontire - Vue Contrleur Entity - Objets mtier - modle vue1
a1
<<useCaseRealization>> uc1
Vopc vue1 e1 c1 e2
m3
c1
uc1
e1 e2
vue2
uc2 a3
protocole
m1 m2
c2
a2
e3
a1
vue1
c1
vue3
uc3
e4 c3
201
RAII : Prsentation du pb
out
Tout sest mal pass et en plus On ne libre pas les ressources
202
(RAII) la sauce Java (Finally)
203
RAII la sauce C++

Selon l'approche RAII, on peut modifier la classe Datafile pour qu'elle fasse le Open() dans son constructeur (avec leve d'exception), et le Close() dans son destructeur. Puis l'on cre une petite classe utilitaire DBLock qui gre le verrouillage de la base :
204
Patterns et architecture
MVC
FrameWork Organisation des packages
Mtriques
205
Patterns et architecture
MVC FrameWork Organisation des packages Mtriques
206
1
Controleur
MVC
3 4
Vue
Modele
(Origine :SmallTalk-Xerox) 1. L'utilisateur a fait qq chose (bouton, menu, .) 2. Le contrleur prvient le modle 3. Modification d'IHM (bouton non disponible, menu gris, ) 4. Le modle prvient la vue que qq chose est arriv (changement d'tat 5. La vue demande des informations complmentaires Cela permet d'avoir plusieurs vues, plusieurs modles 207
MVC : Design pattern compos

laVue
Strategie
Stratgie/etat
ctrl1 +PushButton()
Ctrl2 +ClickMenu()
Controleur
Vue
Composite Observer
Modele
UpDate()
Sujet
208
Utiliser Utilisateur
MVC
Sujet +Attach(o: Vue) +Detach(o: Vue) +Notify() Controleur -state-strategie
Gerer Admin
Systeme -Configurer +Utiliser Configurer Lecture
Utiliser
ObjetMetier Utilisable UtilisableGerable
Util
Conf
Configuration
Vue
+Update()
utilisable gerable
-fabrique-abstraite Gerable
UneVue
LeCtrl
VueDos
VueSwing -composite
209
Framework : Introduction
Dfinition : Un framework est une infrastructure logicielle qui facilite la conception d applications par l'utilisation de bibliothques de classes ou de gnrate de programmes, soit dit en quelques mots : un cadre de dveloppemen
Exemples: Struts est un framework java d'interfaage homme machine pour appli web. SWING est un framework java d'interfaage homme machine pour une application fentre. Les MFC sont un framework C++ d'interfaage d'une application avec systme d'exploitation windows. la GTK est un framework C d'interfaage homme machine avec une application fentre, conu l'origine pour les systmes unix et port sur windows. 210 java est un framework, Dot.net aussi, Junit est un framework de test
Framework : Utilisation
Il existe des frameworks de divers types, et ceux-ci sont complmentair un framework runit l'ensemble des implmentations rcurrentes de no dveloppements. Les avantages en sont : viter de recoder encore et toujours les mmes bouts de codes rba agir en un point unique pour modifier l'ensemble du comportement applicatif (Par exemple le "look and feel") faisant profiter toutes les applications des avances du framework, assurer la robustesse de ces parties du code (rptitives et essentie
Exemple Spring : Java JEE est trop compliqu(pas d'hritage et de polymorphisme ave Les EJB. Struts pour la prsentation Hibernate pour la persistance
211
Composant
Un composant est form avec: Une interface dfinissant la structure objet ncessaire la ralisation travail (ou plusieurs) son implmentation.
Runir un ensemble des classes et des interfaces ayant des comportem agissant dans le mme sens au sein de composants. Les divers composants communiquent par le biais d'une Faade.
212
Organisation des packages

H A B
E D F I
G L J K
213
Organisation des packages

Op1 {b.Fqq()} Op2 {a.Fqq()}
: Application
:A
monB : B
monA : A
Op1( ) Fqq( ) Op2( ) Fqq( )
214
Dpendances cycliques : Interface

L'application : Cre un objet A Cre un objet B Prsente B A en tant que FqqAble Prsente A B en tant que FqqAble
215
Mtriques (1)
Lines of Code (LOC): Le nombre total de lignes de code. Les lignes blanches et les commentaires ne sont pas comptabiliss Number of Static Methods (NSM): Le nombre de mthodes statiques dans l'lment slectionn. Afferent Coupling (CA): Le nombre de classes hors d'une package qui dpendent d'une classe dans le package Normalized Distance (RMD): RMA + RMI - 1: Ce nombre devrait tre petit, proche de zro pour indiquer une bonne conception des parquets. Number of Classes (NOC): Le nombre de classes dans l'lment slectionn. Specialization Index (SIX): NORM * DIT / NOM: Moyenne de l'index de spcialisation. Instability (RMI): CE / (CA + CE) : Ce nombre vous donnera l'instabilit de votre projet. C'est--dire les dpendances entre les paquets. Number of Attributes (NOF): Le nombre de variables dans l'lment slectionn. Number of Packages (NOP): Le nombre de packages dans l'lment slectionn. Method Lines of Code (MLOC): Le nombre total de lignes de codes dans les mthodes. Les lignes blanches et les commentaires ne sont pas comptabiliss Weighted Methods per Class (WMC): La somme de la complexit cyclomatique de McCabe pour toutes les mthodes de la classe. Number of Overridden Methods (NORM): Le nombre de mthodes redfinies. Number of Static Attributes (NSF): Le nombre de variables statique. Nested Block Depth (NBD): La profondeur du code
216
Mtriques (2)
Number of Methods (NOM): Le nombre de mthodes . Lack of Cohesion of Methods (LCOM): Une mesure de la cohsion d'une classe. Plus le nombre est petit et plus la classe est cohrente, un nombre proche de un indique que la classe pourrait tre dcoupe en sous-classe. Nanmoins, dans le cas de Javabean, cette mtrique n'est pas trs correcte, car les getteurs et les settteurs sont utiliss comme seules mthodes d'accs aux attributs. Le rsultat est calcul avec la mthode d' Henderson-Sellers : on prend m(A), le nombre de mthodes accdant un attribut A, on calcule la moyenne de m(A) pour tous les attributs, on soustrait le nombre de mthodes m et on divise par (1-m). McCabe Cyclomatic Complexity (VG): La complexit cyclomatique d'une mthode. C'est--dire le nombre de chemins possibles l'intrieur d'une mthode, le nombre de chemin est incrment par chaque boucle, condition, oprateur ternaire, # Il ne faut pas que ce nombre soit trop grand pour ne pas compliquer les tests et la comprhensibilit de la mthode. Number of Parameters (PAR): Le nombre de paramtres. Abstractness (RMA): Le nombre de classes abstraites et d'interfaces diviss par le nombre total de classes dans un package. Cela vous donne donc le pourcentage de classes abstraites par package Number of Interfaces (NOI): Le nombre d'interfaces. Efferent Coupling (CE): Le nombre de classes dans un packages qui dpendent d'une 217 classe d'un autre package.
Mtriques (3)
Number of Children (NSC): Le nombre total de sous-classes directes d'une classe Depth of Inheritance Tree (DIT): Distance jusqu' la classe Object dans la hirarchie d'hritage. Graphe de dpendances entre packages
http://metrics.sourceforge.net/update
218
Vido Google : DP & Python : http://www.aleax.it/goo_pydp.pdf (2h)Alex Martelli
Bibliographie
Valtech : Management Agile Christophe Addinquy (27mn) David Gageot (17 mn) Xp ca marche vraiment ? (rgis Medina 18mn)
TV4IT : Eric Groise Michel Cara

219
Table des matires

Les patterns Grass 5 Principes fondamentaux de conception 14 Processus objet (up-xp) 32 Processus objet (test-refactoring) 52 ______________________________________ Les design patterns 70 Les design patterns de comportement 75 Automate 76 Stratgie 86 Patron de mthode 90 Observeur 96 Visiteur 105 Memento 110 Iterateur 115 Chane de responsabilit 121 Commande 125 Interprteur 130 Mdiateur 131 Les design patterns de structure 132 Proxy 133 Decorateur 147 Adaptateur 158 Composite 162 Faade 167 Poids mouche 171 Pont 173 Les designs patterns de cration 175 Singleton 176 Fabrication 179 Fabrication abstraite 186 Builder 190 Prototype 195 _______________________________________ Autres Patterns 200 Les classes d'analyse 201 Raii 202 Patterns et architecture 205 MVC 207 Mtriques 216 Bibliographie 219
220
Junit 3.8->4
221
Junit & DP
222
Hritage versus composition

Stack pile = new Stack(); pile.push("Bas de la pile"); pile.push("Haut de la pile"); pile.insertElementAt("Perdu", 0); while (!pile.empty()) { System.out.println(pile.pop()); }
Vector Stack
import java.util.logging.*; public class LoggedList extends ArrayList { private static final Logger LOG = Logger.getLogger("logged lists"); public void add(E element) { LOG.info("Added element: " + e.toString()); super.add(e); } public boolean addAll(Collection c) { for (E e : c) { LOG.info("Added element: " + e.toString()); } super.addAll(c); }
ArrayList
LoggedList
223
RMI : Securit
Depuis java2, utiliser la scurit sur le SujetReel et le Client Rajouter System.setSecurityManager(new RMISecurityManager()); Les lancer avec l'option : java -Djava.security.policy=policy.all SujetReel
grant { permission java.security.AllPermission; };
224
RMI :UML
(Sujet)Naming.lookup
rmiregistry
Client +main() Remote
UnicastRemoteObject
<<interface>> Sujet +Afficher(): void raises RemoteException
SujetReel +Afficher(): void raises RemoteException +SujetReel() raises RemoteException +main() <<exception>> RemoteException
main: SujetReel leSujetReel = new SujetReel(); Naming.rebind("BonjourDeLoin", leSujetReel);
225
//Sujet.java import java.rmi.*; public interface Sujet extends Remote { public void Afficher() throws RemoteException; } //SujetReel.java import java.rmi.*; import java.rmi.server.*; public class SujetReel extends UnicastRemoteObject implements Sujet { public SujetReel() throws RemoteException{super();}; public void Afficher(){System.out.println ("Bonjour");} public static void main(String args[]) { try { System.setSecurityManager(new RMISecurityManager()); SujetReel leSujetReel = new SujetReel(); Naming.rebind("BonjourDeLoin", leSujetReel); }catch (Exception e) {System.out.println ("excpt");} System.out.println("Le sujet est pret"); } }
226
// Client.java import java.rmi.*; import java.rmi.server.*; import java.rmi.registry.*;

public class Client {
public static void main(String args[]) { System.setSecurityManager(new RMISecurityManager()); try{ Sujet monSujet = (Sujet)Naming.lookup("rmi://127.0.0.1/BonjourDeLoin") monSujet.Afficher(); }catch (Exception e) {System.out.println ("excpt");} } }
227
RMI :Mise en ouvre
228
Automate-Tableau
229
Refactoring-Mtriques
Avant Avant
Aprs Aprs
230
Abuser Metriques
Sans DP
Avec DP
231
LocomotiveSurCoussin lr =new LocomotiveSurCoussin(); WagonSurRail wr =new WagonSurRail(); lr.Accrocher(wr); lr.Rouler(); FabriqueAbstraite f1 ; Locomotive lrail; La loco sur coussin d'air vole Wagon wrail ; La wagon sur rail roule f1 = new FabriquePourRail(); La loco sur rail roule lrail = f1.CreerLocomotive(); La wagon sur rail roule wrail = f1.CreerWagon(); La loco sur coussin d'air vole lrail.Accrocher(wrail); La wagon sur coussin d'air vole lrail.Rouler(); f1 = new FabriquePourCoussin(); lrail = f1.CreerLocomotive(); wrail = f1.CreerWagon(); lrail.Accrocher(wrail); lrail.Rouler();
232
<<interface>> FabriqueAbstraite ~CreerLocomotive(): Locomotive ~CreerWagon(): Wagon
<<interface>> Locomotive ~Rouler() ~Accrocher(p: Wagon)
LocomotiveSurRail +Accrocher(w: Wagon) +Rouler()
LocomotiveSurCoussin +Accrocher(w: Wagon) +Rouler()
-monWagon -monWagon FabriquePourRail +CreerLocomotive(): Locomotive +CreerWagon(): Wagon FabriquePourCoussin +CreerLocomotive(): Locomotive +CreerWagon(): Wagon <<interface>> Wagon ~Rouler()
WagonSurRail +Rouler()
WagonSurCoussin +Rouler()
233
Le Robot
234
235
Le Robot : Composite
Composite
236
237
238
Mtriques : Instability
Afferent Coupling (CA): Le nombre de classes hors d'une package qui dpendent d'une classe dans le package Efferent Coupling (CE): Le nombre de classes dans un packages qui dpendent d'une classe d'un autre package. Instability (RMI): CE / (CA + CE) : Ce nombre vous donnera l'instabilit de votre projet. C'est--dire les dpendances entre les paquets.
CA = 0 CE = 2 RMI = 1
CA = 2 CE = 1 RMI = 0,33
CA = 2 CE = 0 RMI = 0
239

Design Patterns Java 1222499509564319 8

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Design Patterns Java 1222499509564319 8

Transféré par

Droits d'auteur :

Formats disponibles

B.

Design Patterns JAVA

Pourquoi faire de l'objet(1) ?

Pourquoi faire de l'objet(2) ?

Introduction aux Design Patterns

Les Patterns : Introduction

Les Patterns : Dfinition

Exemple : Les Patterns Grasp

Le pattern GRASP : Expert

Le pattern GRASP : Crateur

Le pattern GRASP : Couplage

Le pattern GRASP : Cohsion

Le pattern GRASP : Contrleur

Principes fondamentaux de conception

Les objectifs du DESIGN

Gestion des volutions et des dpendances entre classes

Principe dinversion des dpendances Dependency Inversion Principle (DIP)

Exemple : utilisation de la dlgation abstraite (OCP)

Lapplication de lOCP est un choix stratgique (OCP)

classes de l'application en vue d'ventuels changements.

Il convient donc d'identifier correctement les points d'ouverture/fermeture de l'application, en s'inspirant :

des besoins d'volutivit exprims par le client,

des besoins de flexibilit pressentis par les dveloppeurs,

La mise en oeuvre de ce principe reste donc une affaire de bon sens.

Appl3 Avec adr

Exemple : (OCP) Solution

pas besoin de faire de VNR (faites la quand mme)

Principes de substitution de LISkOV (LSP)

Principes de substitution de LISkOV (LSP) : exemple

Que se passe-t-il si le Rectangle est un carr?Hritage<>Composition

Principes dinversion des dpendances (DIP)

<<interface>> IObjetMetier IObjetMetier

Principes dinversion des dpendances (DIP)

possible de rutiliser la logique d'une application en dehors du contexte

La relation de dpendance doit tre inverse :

Labstraction comme technique dinversion des dpendances (DIP)

Principes de sparation des interfaces (ISP)

Principes de sparation des interfaces (ISP)

Solution : sparation des services de l'interface

Principes de sparation des interfaces (ISP)

Techniques de sparation (ISP)

Sparation par hritage multiple (ISP)

Sparation par adaptateur (ISP)

Winston Royce. Managing the Development of Large Software Systems. 1970

UP: Caractristiques essentielles

UP & les modles UML (1)

UP & les modles UML (2)

Modle dimplmentation Modle de test Modle de dploiement Modle d'architecture

UP & L'organisation matricielle

Pourquoi une nouvelle Mthode ?

Les mthodes agiles

Les valeurs d' XP (1)

Les valeurs d' XP (2)

Les principes de base

La planification est un jeu

Junit : Ecrire le test

Junit : lancement du test

Tests : Les couches

Le Refactoring :Principes (1)

Le Refactoring :Principes (2)

Le refactoring dans Eclipse (1)

et les dclarations d'exceptions.

Le refactoring dans Eclipse (2)