Download - Design Patterns Java
![Page 1: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/1.jpg)
1
Design Patterns JAVA
Conception d’applications objet
B.Vinot
![Page 2: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/2.jpg)
2
Contenu du cours
• Introduction aux DP• Principes fondamentaux de conception
• Les patterns GRASS• Ouverture-Fermeture (OCP)• Inversion des dépendances (DIP)• Substitution de Liskov (LSP)• Séparation des interfaces (ISP)
• Méthodes de DVP et Processus• Up – XP• Tests et Refactoring
• Les design patterns• Les DP du GOF (23)
• Comportement (11)• Structure (7)• Création (5)
• Autres Patterns •Les Patterns d'analyse• Le Raii
• Organisation• MVC• Les frameworks• Les composants• Les packages• Métriques
![Page 3: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/3.jpg)
3
Pourquoi faire de l'objet(1) ?
17
11
81714
11
7
6
2
2
5
IncreasedProductivity
Cost savings
Improvedinterfaces
Software reuse
Improvedapplicationmaintenance
Encapsulateexistingapplications
Develop strategicapplicationsquickly
Developapplications asrevenue source
Access new OSand tools
![Page 4: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/4.jpg)
4
Pourquoi faire de l'objet(2) ?
C++ C++ C++ C C CV0 V1 V2 V0 V1 V2
Average Function LOC 6,66 6,2 6,11 29,62 32,5 37,11Min Function LOC 2 1 1 3 3 3Avg Cyclomatic Complex 1,66 1,59 1,59 5,88 6,25 6,56Avg Comparison Complex 0,25 0,24 0,3 1,38 1,62 2,22Avg Logic Flow Complex 1,91 1,83 1,89 7,25 7,88 8,78Avg Function Complexity 3,69 3,59 3,7 9 9,62 10,56eLoc/100 2,07 2,5 2,68 2,68 2,91 3,53eLOC 207 250 268 268 291 353
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 35
The Alternative: Allow Iteration
Escher was the first:-)
C++ C++ C++ C C CV0 V1 V2 V0 V1 V2
Average Function LOC 6,66 6,2 6,11 29,62 32,5 37,11Min Function LOC 2 1 1 3 3 3Avg Cyclomatic Complex 1,66 1,59 1,59 5,88 6,25 6,56Avg Comparison Complex 0,25 0,24 0,3 1,38 1,62 2,22Avg Logic Flow Complex 1,91 1,83 1,89 7,25 7,88 8,78Avg Function Complexity 3,69 3,59 3,7 9 9,62 10,56eLoc/100 2,07 2,5 2,68 2,68 2,91 3,53eLOC 207 250 268 268 291 353
![Page 5: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/5.jpg)
5
Introduction aux Design Patterns
Les Patterns GRASS
General ResponsabilityAssignement Software Patterns
![Page 6: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/6.jpg)
6
Les Patterns : Introduction
Naissance des patterns : Les patterns furent utilisés bien avant que les
systèmes d’informations modernes n’apparaissent, dans d’autres
disciplines comme la construction et l’architecture de bâtiments. 1987, Beck et Cunningham définissent 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 décrit des modèles de conception plus intuitifs : les
Patterns GRASP : General Responsability Assignement Software
Patterns, ou patterns généraux d’affectation des responsabilités.
![Page 7: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/7.jpg)
7
Les Patterns : Définition Un design pattern est un modèle de conception. Au fur et à mesure des
développements, des principes généraux répétitifs sont remarqués, et
des solutions courantes sont identifiées. En formalisant celles-ci, sous
la forme de la présentation d’un problème de conception, et de la
solution pour le résoudre, on obtient un design Pattern. Un design pattern doit répondre à certains aspects essentiels :
Un pattern a un nom évocateur, qui représente bien l’essence même
de son existence. Exemple : le pattern GoF « Singleton » Un pattern résout un problème. Exemple : une classe ne peut avoir
qu’une et une seule instance disponible. Un pattern fourni une solution-génie (voir le pattern singleton plus
loin) Un pattern doit être expliqué (documentation-uml)
![Page 8: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/8.jpg)
8
Exemple : Les Patterns Grasp
C’est presque du bon sens L’expert (affectation des responsabilités) Le créateur Faible couplage Forte cohésion Contrôleur
![Page 9: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/9.jpg)
9
Le pattern GRASP : Expert
Qui fait quoi :
le modèle Expert est un pattern relativement intuitif, qui en général, est
respecté par le bon sens du concepteur. Il s’agit tout simplement
d’affecter à une classe les responsabilités correspondants aux
informations dont elle dispose intrinsèquement (qu’elle possède) ou
non ( objets de collaborations ).on ne peut exiger d’un réfrigérateur qu’il fasse radiateur et range-
disquesDonner des définitions (c'est très difficile)
int i; // variable i entière
Voiture
+voilure+surface+poids+vitesse+pente
+Rouler()+Voler()+Manger()+Travailler()
Maison
+age+queue+lit+lampe
+Allumer()+Vendre()+Vieillir()+Dormir()
Personne
-nom: String-age: int
+Metro()+Boulot()+Dodo()
![Page 10: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/10.jpg)
10
Le pattern GRASP : Créateur
Qui crée qui? :
Ce pattern consiste en la détermination de la responsabilité de la création
d’une instance d’une classe par une autre. Une classe A agrége des instances de la classe B Une classe A contient des instances de la classe B Une classe A utilise des instances d’une classe B Une classe A possède les données nécessaires à l’initialisation des
instance de classe B, etc.… Variables globales! Notion de configurateurDéléguer la fabrication à qq d’autre! Persistance (JDBC,DAO)
![Page 11: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/11.jpg)
11
Le pattern GRASP : Couplage
Le couplage exprime la relation étroite qu’un élément (Classe, Système
ou sous système) entretien avec un ou des autres éléments. Un élément
faiblement couplé ne possède pas ou peu de dépendances vis a vis
d’autres éléments. Les objets sont couplés (paresseux) Un objet qui est connu de personne est inutile. Un objet qui connaît personne ne fait pas grand chose (sauf Utility) Parler à des classes abstraites plus tôt qu’à des classes concrètes
![Page 12: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/12.jpg)
12
Le pattern GRASP : Cohésion
Esprit de famille
La cohésion mesure le degré de spécialisation des responsabilités d’un
composant / classe. La cohésion médiocre altère la compréhension, la réutilisation, la
maintenabilité et subit toute sorte de changements. Exception pour Corba, RMI, …..(pb de granularité)
Personne Logement Vehicule
![Page 13: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/13.jpg)
13
Le pattern GRASP : Contrôleur
Le contrôleur contrôle. Il est entre la vue et les entités (MVC)
Une classe Contrôleur doit être crée si elle répond à l’un des cas suivants
La classe représente une contrôleur de façade, c’est à dire
l’interface d’accès à l’ensemble d’un système. La classe représente le scénario d’un cas d’utilisation. On le
nomme en général « Session », et est chargé de traiter tous les
événements systèmes contenus dans un scénario de cas d’utilisation.Un contrôleur contient :
Ce qui ne concerne pas la vue Ce qui ne concerne pas les entités (Expert)
![Page 14: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/14.jpg)
14
Principes fondamentaux de conception
Ouverture-Fermeture OCPInversion des dépendances DIP
Substitution de Liskov LSP Séparation des interfaces ISP
![Page 15: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/15.jpg)
15
Les objectifs du DESIGN
Éviter les phénomènes de dégénérescence de l'application Du point de vue du design, trois risques principaux pénalisent les
activités de développement : 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 réutiliser dans une autre application.
Réutilisation
![Page 16: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/16.jpg)
16
Gestion des évolutions et des dépendances entre classes
Principe d’ouverture/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 d’inversion des dépendances Dependency Inversion Principle (DIP)
Utiliser des Interfaces
Principe de séparation des interfaces Interface Segregation Principle (ISP)
Diviser les interfaces
![Page 17: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/17.jpg)
17
Exemple : utilisation de la délégation abstraite (OCP)
A gère les cas c1 et c2. Si un nouveau cas c3 doit être géré, il faut modifier le code de A en conséquence :
![Page 18: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/18.jpg)
18
L’application de l’OCP est un choix stratégique (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 néfaste si la flexibilité recherchée
n'est pas réellement exploitée. Il convient donc d'identifier correctement les points d'ouverture/fermeture de
l'application, en s'inspirant :
des besoins d'évolutivité exprimés par le client,
des besoins de flexibilité pressentis par les développeurs,
des changements répétés constatés au cours du développement.
La mise en oeuvre de ce principe reste donc une affaire de bon sens.
![Page 19: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/19.jpg)
19
Exemple : (OCP)
Personne
nom : stringage : int
Personne(n : string, a : int)
Appl1
Appl2
BD
ID nom age
Appl3Avec adr
• Rajouter un attribut• Rajouter un constructeur• Rajoute un paramètre au constructeur
• Faire une nouvelle classe PersonneAdr• Rajouter une méthode getAdr même ds Personne
• Rajouter un attribut• Rajouter un constructeur• Rajoute un paramètre au constructeur
• Faire une nouvelle classe PersonneAdr• Rajouter une méthode getAdr même ds Personne
![Page 20: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/20.jpg)
20
Exemple : (OCP) Solution
Appl1
Appl2
Appl3
Personne
nom : stringage : int
Personne(n : string, a : int)GetAdresse() : string
PersonneDomicilee
adresse : string
PersonneDomiciliee(n : string, a : int, adr : string)GetAdresse() : stringSetAdresse(p : string) : void
Rend une chaîne vide:Appl3 peut alors utiliser des Personnes
Jouer sur les méthodes plus tôt que sur les attributsLes gains : 2 versions dans le même exécutable pas besoin de faire de VNR (faites la quand même)
![Page 21: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/21.jpg)
21
Principes de substitution de LISkOV (LSP)
Pour prétendre à l'héritage, une sous-classe doit être conçue de sorte que ses instances puissent se substituer à des instances de la classe de base partout où cette classe de base est utilisée.
Hériter d’une interface
En insistant sur cette approche de l'héritage, le principe de substitution
s'oppose à une pratique répandue dans laquelle l'héritage est mis en oeuvre
pour factoriser du code entre plusieurs classes.
C0
C1 C2
I0<<Interface>>
C1 C2
![Page 22: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/22.jpg)
22
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));
Rectangle
+longueur: int+largeur: int
+SetValeur(p1: int, p2: int)
Carre
+SetValeur(p1: int, p2: int)
Que se passe-t-il si le Rectangle est un carré?Héritage<>Composition
![Page 23: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/23.jpg)
23
Principes d’inversion des dépendances (DIP)
Dans la plupart des applications, les modules de haut niveau (ceux qui portent la logique fonctionnelle de l'application ou les aspects "métier") sont construits directement sur les modules de bas niveau (par exemple les librairies graphiques ou de communication) :" Le passage à l'abstrait est valorisé"
ObjetMetier
IHM ObjetMetier
IHM
ObjetMetier
IHM
IObjetMetier<<interface>>
ObjetMetier
IHM
IObjetMetier
![Page 24: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/24.jpg)
24
Principes d’inversion des dépendances (DIP)
Cela paraît naturel au premier abord mais pose en réalité deux problèmes essentiels : Les modules de haut niveau doivent être modifiés lorsque les modules de
bas niveau sont modifiés. Il n'est pas possible de réutiliser les modules de haut niveau
indépendamment de ceux de bas niveau. En d'autres termes, il n'est pas
possible de réutiliser la logique d'une application en dehors du contexte
technique dans lequel elle a été développée. La relation de dépendance doit être inversée :
les modules de bas niveau doivent se conformer à des interfaces définies
et utilisées par les modules de haut niveau.
![Page 25: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/25.jpg)
25
L’abstraction comme technique d’inversion des dépendances (DIP)
Considérons deux classes A et B, A utilisant B comme indiqué sur le schéma ci-dessous :
Pour inverser la dépendance de A vers B, on introduit une classe d'interface I dont dérive B comme suit :
![Page 26: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/26.jpg)
26
Principes de séparation des interfaces (ISP)
Pollution d'interface par agrégation de servicesOn retrouve dans la plupart des designs quelques classes qui rendent plusieurs
services simultanément, comme l'illustre le schéma ci-dessous :
![Page 27: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/27.jpg)
27
Principes de séparation des interfaces (ISP)
L'inconvénient 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'intéresse pas,Chaque client peut être impacté par des changements d'une interface qu'il n'utilise pas.
Solution : séparation des services de l'interfaceLe principe de séparation des interfaces stipule que chaque client ne doit "voir" que les services qu'il utilise réellement
![Page 28: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/28.jpg)
28
Principes de séparation des interfaces (ISP)
![Page 29: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/29.jpg)
29
Techniques de séparation (ISP)
Il existe deux techniques principales de mise en pratique de l'ISP :
L'héritage multiple,
Le Design Pattern "Adapter".
![Page 30: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/30.jpg)
30
Séparation par héritage multiple (ISP)
Dans cette approche chaque service est représenté par une classe d'interface dont dérive la classe qui implémente les services. Les clients ne voient les services qu'au travers de ces classes d'interface comme le montre le schéma suivant :
![Page 31: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/31.jpg)
31
Séparation par adaptateur (ISP)
Lorsque l'héritage multiple n'est pas possible, les services peuvent être représentés par des classes d'adaptation :
![Page 32: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/32.jpg)
32
Processus ObjetUP
XP-Agile
Winston Royce. Managing the Development of Large Software Systems. 1970
![Page 33: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/33.jpg)
33
UP: Caractéristiques essentielles
Caractéristiques 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 d’utilisation,-Centré sur l’architecture
(plate-forme, performances, réutilisation, indépendantedes UC, Y, …)
- Itératif et incrémental.
UPRUPXUP
![Page 34: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/34.jpg)
34
UP & les modèles UML (1)
![Page 35: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/35.jpg)
35
UP & les modèles UML (2)Modèle des cas d’utilisation
Expose les cas d’utilisation et leurs relations avec les utilisateurs
Modèle d’analyse Détaille les cas d’utilisation et procède à une
première répartition du comportement du système entre divers objets
Modèle de conception
Définit la structure statique du système sous
forme de sous système, classes et interfaces ;
Définit les cas d’utilisation réalisés sous forme de collaborations entre les sous systèmes les classes et les interfaces
Modèle d’implémentation
Intègre les composants (code source) et la
correspondance entre les classes et les composants
Modèle de test Décrit les cas de test vérifiant les cas d’utilisation
Modèle de déploiement
Définit les nœuds physiques des ordinateurs et
l’affectation de ces composants sur ces nœuds.
Modèle d'architecture
Description de l’architecture (réutilisable)
![Page 36: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/36.jpg)
36
UP & L'organisation matricielle
![Page 37: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/37.jpg)
37
Processus Objet
XP-Agile
Extrem programing
La programmation extrême
Les processus agiles
![Page 38: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/38.jpg)
38
Pourquoi une nouvelle Méthode ?
Les approches classiques de développement type "waterfall", basées sur la fameuse Séquence spécification / conception / réalisation / validation, souffrent de problèmes chroniques :
• Les spécifications sont définies au début du projet, alors qu'on en sait encore peu sur le sujet,• Les spécifications différencient 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 activités sont compartimentées en fonction des spécialités des développeurs, ce qui pose des problèmes de répartition des tâches et limite la circulation des connaissances dans l'équipe.
![Page 39: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/39.jpg)
39
Les méthodes agiles
• Année 80 : RAD (100 jours)• Année 90 : XP (Chrysler) et DSDM (Angleterre)
(Dynamic Software Development Method)• 2001 : Le manifeste Agile
• individus et interactions plutôt que processus et outils• développement logiciel plutôt que documentation exhaustive• collaboration avec le client plutôt que négociation contractuelle• ouverture au changement plutôt que suivi d’un plan rigide
![Page 40: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/40.jpg)
40
Les valeurs d' XP (1) Communication
XP intègre réellement le client au projet pour qu'il définisse mieux ses besoins, arbitre les priorités et apporte ses connaissances métier à l'équipe.XP fait travailler tous les développeurs ensemble et les fait participer à toutes les activités du développement, créant ainsi une réelle dynamique d'équipe.XP rend accessible à tous les intervenants l'ensemble des indicateurs d'avancement du projet.
FeedbackXP fournit des livraisons régulières au client pour lui permettre d'affiner et de compléter la définition de ses besoins à partir de données concrètes.XP met en place des batteries de tests d'acceptation qui mesurent concrètement l'avancement des développements.XP met en place des batteries de tests unitaires qui indiquent rapidement si le code fonctionne et qui détectent instantanément toute régression.
![Page 41: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/41.jpg)
41
Les valeurs d' XP (2)Simplicité
XP s'assure que seules les fonctionnalités demandées par le client sont implémentées.
XP maintient un design et un code toujours aussi simples que possible pour rester ouvert au changement et conserver une grande vitesse de développement tout au long du projet.
Courage
XP donne au jour le jour une transparence maximale sur l'état d'avancement réel du projet.
XP s'attaque aux problèmes dès qu'ils se présentent, en autorisant des retours en arrière s'ils sont nécessaires.
![Page 42: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/42.jpg)
42
Binôme (1)
•Binôme–Bien perçu des programmeurs
–Garantit l’homogénéité du code, le respect des règle 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 binômes
–Répartition des compétences
![Page 43: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/43.jpg)
43
Binôme (2)•Exploration d’un problème (Spike - CrcCards)•Nom des objets (bonne compréhension)
–Prendre le temps de bien le faire (Métaphore local)•Documenter le code
–Pas de documentation mais un code bien commenté (Déclaration)•Espace de travail
–Espace de développement central–Bureautique en périphérie–Grande table de réunion dans le bureau–Grand écrans pour le développement–Tout le monde se voit (mobilier spécifique?)
![Page 44: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/44.jpg)
44
TU
•Tests unitaires–Aide à la conception détaillé–Systématiquement avant le code (inhabituelle)–Ne doit pas passer au début (Iconoclaste?) –Ne pas développer plus que ce qui est nécessaire pour le test–Auto-vérifiant (18000 tests passés en 15 mn-tests passés de 15 mn
À 20 secondes)–Tous les tests de tous les modules doivent passer sans erreur avant
d’intégrer le code–Super aide à la non régression, au changement de conception et
au remaniement– Cela peut être mis en œuvre hors de XP
![Page 45: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/45.jpg)
45
La Planification
•La planification collective en début d’incrément (Une journée)–Incrément de trois semaines
–Lecture et explications des user stories (cas d’utilisation)
–Grandes lignes de la conception
–Définition et évaluation des tâches
•Évaluation en temps idéal + Load factor–Évaluation en deux groupes. Le minimum est choisi si aucune
difficulté n’a été oubliée.
![Page 46: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/46.jpg)
46
Conditions d’application
Il faut :• Une équipe qui s’entende bien et réduite (12 max)• Développement mono site• Programmation par composants• Que le client participe et adhère
Il ne faut pas:• Une spécification complète et détaillée du futur système• Mesurer la qualité de la documentation au poids
![Page 47: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/47.jpg)
47
Les principes de base
• Seul le code source fait foi, il possède une odeur• L’important c’est le programmeur• Faire le plus simple possible• Restructurer dès que nécessaire• Pratiquer la programmation par paire• Les spécifications sont des « histoires d’utilisateurs »• La planification est un jeu• Livrer fréquemment• Tester encore, toujours et tout le temps• Être courageux
![Page 48: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/48.jpg)
48
histoires d’utilisateurs
• Des descriptions rédigées par les utilisateurs (clients)• Pour chaque histoire :
• le client donne :• Priorité• Tests d’acceptation
• Les développeurs :• Estimation de la charge de la réalisation
(l’histoire peut être découpée en tâches)
Une histoire est une unité de livraison
RMQ : Une histoire est un très gros use case
![Page 49: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/49.jpg)
49
La planification est un jeu
XP tente de désamorcer les conflits
Client Développeur
Définition des itérations : • Histoires avec les priorités• Proposer des choix au client
Un vrai dialogue
![Page 50: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/50.jpg)
50
Être courageux• Standup meeting• Choisir des tâches que l’on ne sait pas faire• Accepter d’expliquer aux autres ce que l’on sait• S’arrêter de développer pour faire du refactoring• Accepter de ne pas être responsable, alors qu’on est plus fort• Ne pas avoir les yeux plus gros que le ventre
![Page 51: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/51.jpg)
51
Déroulement
Scrum
![Page 52: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/52.jpg)
52
Processus Objet
Tests
Refactoring
![Page 53: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/53.jpg)
53
Test et Junit
Personne
-nom: String~age: int
<<create>>+Personne(n: String, a: int)+getAge(): int+setAge(age: int)+getNom(): String+setNom(nom: String)~Afficher()~Travailler()
Entreprise
-lesEmployes: ArrayList = new ArrayList()
+Embaucher(p: Personne)+Virer(p: Personne)+nbEmploye(): int+Faillite()
-lesEmployes 0..*
![Page 54: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/54.jpg)
54
Junit
![Page 55: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/55.jpg)
55
Junit : Ecrire le testpackage 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); }
}
![Page 56: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/56.jpg)
56
Junit : lancement du test
Regrouper les tests :Sur un projet ou un packageFaire new JunitTestSuite(Other)
Junit4
![Page 57: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/57.jpg)
57
Tests : Les couches
Blabla
Objetsmétier
CTRL
BD
Serialisation
• Les objets métier offrent des interfaces pour les IHM (le CTRL)• En analyse : Les trois axes d' une classe
Stringglobal
![Page 58: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/58.jpg)
58
Couverture de test
![Page 59: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/59.jpg)
59
Le Refactoring :Principes (1)
Programmer au plus simple Faire du refactoring tout le temps (comme le ménage) Faire des itérations spéciales S’assurer que :
Les tests existent Ils sont OK
Faire des petites choses Renommer Découper Déplacer
![Page 60: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/60.jpg)
60
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)
![Page 61: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/61.jpg)
61
Le refactoring dans Eclipse (1)
Extract Method : Crée une nouvelle méthode encapsulant les éléments sélectionnés,
et remplace toutes les références à ces éléments (même ailleurs dans le code), par un
appel vers cette méthode.
Rename : Renomme l'élément sélectionné.
Move : Déplace l'élément sélectionné, 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 méthode en cours, c'est-à-
dire ses droits d'accès (public / private / protected / default). Peuvent également être
modifiés par cet assistant : le type du résultat, l'ordre, le nom et le type des
paramètres et les déclarations d'exceptions.
Convert Local Variable to Field : Transforme une variable locale, définie dans une
méthode, en champ de classe
![Page 62: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/62.jpg)
62
Le refactoring dans Eclipse (2) Extract Local Variable : De la même manière que Extract Method,
cette fonction crée une nouvelle variable assignée à l'expression
sélectionnée.
Inline : C'est la fonction inverse de Extract Local Variable : elle rétablit
l'expression assignée à la variable, en lieu et place de la variable, qui
disparaît. Particulièrement utile si l'on se rend compte qu'une variable
locale n'est utilisée qu'une fois, et que le programme n'est jamais assez
optimisé.
Push Down... Pull Up : Ces deux fonctions marchent dans le même
sens, mais avec des directions différentes : elles déplacent la sélection
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ù ce remplacement est possible.
![Page 63: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/63.jpg)
63
Le refactoring dans Eclipse (3)
Extract Interface : À l'instar des précédentes fonctions de types
Extract, celle-ci se charge de prendre les éléments sélectionnes et d'en
tirer une classe disposant des méthodes de la classe en cours, et
implémente cette interface sur la classe.
Encapsulate Field : Remplace toutes les références à un champ de
classe, par des méthodes get et set pour ce champ.
Introduce Factory : Crée une nouvelle méthode de type Factory (voir
plus loin), en générant pour un constructeur donné la méthode statique
appropriée.
![Page 64: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/64.jpg)
64
Le refactoring dans Eclipse (4)
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. .
![Page 65: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/65.jpg)
65
Refactoring : exercice(1)
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)
0..*
1
Un film • une catégorie (enf, norm, nouv)• un titre
Une location• concerne un film• une durée
Coût de la location• norm : 2 + 1.5 par jour au de la du deuxième jour• nouv : 3 par jour• enf : 1.5 + 1.5 par jour au de la du troisième jour
Bonus : Chaque location donne un point, si une nouveauté est louée plusqu'un jour, alors un point supplémentaire.
![Page 66: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/66.jpg)
66
Refactoring : exercice(2)
![Page 67: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/67.jpg)
67
Refactoring : exercice(3)
![Page 68: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/68.jpg)
68
Refactoring : correction
Main_1
+main(args: String)
Client
-nom: String-lesLocations: Vector = new Vector()
<<create>>+Client(name: String)+addRental(arg: Location)+getNom(): String+statement(): String
Location
-film: Film-duree: int
<<create>>+Location(movie: Film, d: int)+getDuree(): int+getFilm(): Film+calculerPrix(): double+calculerBonus(): int
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
LocationEnfant
<<create>>+LocationEnfant(f: Film, d: int)+calculerPrix(): double
LocationNouveaute
<<create>>+LocationNouveaute(f: Film, d: int)+calculerPrix(): double
LocationNormal
<<create>>+LocationNormal(movie: Film, d: int)+calculerPrix(): double
![Page 69: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/69.jpg)
69
Les Design patterns
Le GoF
Comportement
Structure
Création
![Page 70: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/70.jpg)
70
Les Design Patterns
• Problème: Comment allouer des objets en mémoire ? • Contexte: un grand nombre d ’objets alloués en mémoire virtuelle. • Solution: identifier les objets amenés à collaborer fréquemment à un certain moment (réalisation d ’un service), et allouer ces objets dans une même page mémoire.
Alexander writes:
Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.
Le choix des Design Patterns et de leur codage est un choix d ’architecture
Les outils permettent d ’instancier les Design Patterns et de générer automatiquement le
code
![Page 71: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/71.jpg)
71
Présentation des patrons de conception
Le patron de conception est l’expression d’une problématique récurrente d’un domaine et la définition d’une solution générique à ce problème.
Le concept n’est pas spécifique à l’informatique puisque son domaine d’origine est l’architecture.
Les patrons de conception introduisent la réutilisation des expériences de conception logicielle
Les problèmes abordés nous sont souvent familiers et les solutions proposées peuvent paraître s’imposer, mais c’est l’utilisation effective et au quotidien de ces préceptes qui constitue le véritable défit et apporte une véritable plus-value.
![Page 72: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/72.jpg)
72
Description des patrons de conceptionUn patron de conception est une description textuelle, éventuellement enrichie de modèles UML, d’un problème de conception et du cœur de sa solution.
Cette description comporte typiquement les éléments suivants :
• Un nom permettant de l’identifier
• Le problème et son contexte
• Les éléments de solution et leurs relations
• Les bénéfices et conséquences induits
Le catalogue le plus connu est celui de Erich Gamma qui recense dans son livre quelques 23 modèles de conception orientée objet
![Page 73: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/73.jpg)
73
Classification des patterns
Création
Comportement
Structure
![Page 74: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/74.jpg)
74
Les Design patterns de comportement (1)
• State : un objet réagit selon son humeur• Stratégie : Faire une chose de différentes manières• Template Methode : Faire une chose de différentes manières
(avec une recette de base)• Observer : certains sont intéresses 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• Chaîne de responsabilité : un élément est attendu par un grand nombre
d'objets
![Page 75: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/75.jpg)
75
Les Design patterns de comportement (2)
• Commande : encapsule une requête dans un objet, et permet les files d'attentes, les journalisassions , et retours en arrière (undo).
• Médiateur : définit un objet qui encapsule la manière dont un ensemble d'objets interagissent.
• Interpréteur : définit un langage ainsi que sa grammaire, et fournit un interpréteur pour utiliser la représentation du langage.
![Page 76: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/76.jpg)
76
l ’Automate : contexteProblème : Un même objet doit répondre à une même sollicitation de
plusieurs manières différentes suivant son état interne. Les opérations
produisent des résultats qui dépendent de l’état interne.
Contexte : Fournir un approche systématique d ’implantation des
diagrammes d ’états UML
Solution : On va dissocier l’état de l’objet de l’objet lui-même. Les états
seront matérialisés par autant de classes, chacune spécialisée dans la gestion
d’un de ces états. L’objet n’a plus qu’à gérer une instance représentant l’état
courant et délègue les appels de méthodes à cette instance. Une classe
parente abstraite ou une interface commune permettra à l’objet de les
manipuler d’une façon homogène.
![Page 77: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/77.jpg)
77
State : PréambuleSoit des stagiaires qui réagissent selon leur humeur :• Si on leur demande de travailler:
• Si c’est le matin, ils écoutent. • Si c’est l’après midi, ils font la sieste. • Si c’est midi juste, ils grognent……
• Si on leur demande de faire un exercice ……….
![Page 78: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/78.jpg)
78
State : UML
Client
Etat
+Op1(Context)+Op2(Context)+Op3(Context)
*
Etat1
+Op1(Context)+Op2(Context)
Etat2
+Op2(Context)+Op3(Context)
Context
+Op1()+Op2()+Op3()~SetEtat(Etat)
Client
Context
+Op1()+Op2()+Op3()-SetEtat(Etat)
Etat
+Op1(): Etat+Op2(): Etat+Op3(): Etat
*
Etat1
+Op1(): Etat+Op2(): Etat
Etat2
+Op2(): Etat+Op3(): Etat
![Page 79: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/79.jpg)
79
State : Participants
Les classes et/ou objets participant dans ce pattern sont:•Context
• Défint la classe principale utilisée par le client• Garde une instance de la sous classe state pour définir l’état courant.
• Etat • Définit l’interface des différents états.
•Concrete State• Chaque sous classe implémente l’interface du State conformément à ce qui est faisable dans cet état.
![Page 80: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/80.jpg)
80
State : Exercice1- La banque
SilverState(0-1000)
do: Interet = 10%
RedState(<0)
do: Interet = 0do: Frais = 15
GoldenState(>1000)
do: Interet = 50%
[ balance > 1000 ]
[ balance < 0 ]
[ balance > 0 ]
[ balance < 1000 ]
[ balance < 0 ]
![Page 81: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/81.jpg)
81
State : Exercice1- La banque
Account
owner : string
Account(string : o)GetBalance() : doubleGetState() : *StateSetState(ps : *State) : voidDeposit(c : double) : voidWithDraw(c : doubble) : voidPayInterest() : void
State
balance : doubleinterest : doublelowerLimit : doubleupperLimit : double
GetAccount() : *AccountSetAccount(p : double) : voidGetBalance() : doubleSetBalance(p : double) : void<<abstract>> Deposit(c : double) : void<<abstract>> WithDraw(p : double) : void<<abstract>> PayInterest() : void
-state#account
RedState
serviceFee : double
Deposit(c : double) : voidWithDraw(p : double) : voidPayInterest() : void
SilverState
Deposit(c : double) : voidWithDraw(p : double) : voidPayInterest() : void
GoldenState
Deposit(c : double) : voidWithDraw(p : double) : voidPayInterest() : void
balance<0 => Interet 0%
Balance entre 0 et 1000 => Interet 10%
Balance > 1000 => Interet 50%
balance<0 => Pénalité de 15
![Page 82: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/82.jpg)
82
State : Exercice1
int main(){Account account("Jim"); account.Deposit(500.0); account.PayInterest (); account.Deposit(300.0);account.PayInterest (); account.Deposit(550.0); account.PayInterest(); account.Withdraw(2000.00);account.PayInterest(); account.Withdraw(1100.00) ;account.Withdraw(1000);account.PayInterest();account.Deposit(2000);return 0;}
Gold
Silverr
Silver
Red
Silver
![Page 83: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/83.jpg)
83
State + SingletonE1
E2E3
C1
C2
C3
C2
C1
C2
C3
C1() {monEtat->C1(this)}
E1
$ instance : *E1
$GetInstance() : *E1C1(p : *Objet)C2(p : *Objet)
<<Singleton>>E2
$ instance : *E2
$GetInstance() : *E2C1(p : *Objet)C2(p : *Objet)C3(p : *Objet)
<<Singleton>>
E3
$ instance : *E3
$GetInstance() : *E3C2(p : *Objet)C3(p : *Objet)
<<Singleton>>
Etat
C1(p : *Objet)C2(p : *Objet)C3(p : *Objet)
Objet
C1()C2()C3()SetState(p : *Etat)
+monEtat
C1(--) {"Erreur"}
C1() {"OK"}C2() {"OK";p->SetState (E2)}
![Page 84: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/84.jpg)
84
State + SingletonExo2
E1
E2E3
C1
C2
C3
C2
C1
C2
C3
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();
![Page 85: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/85.jpg)
85
State : Remarques
Remarques :- Les états concrets peuvent posséder une référence à l’objet (possibilité
pour l ’état concret de manipuler les attributs de l ’objet)
- Le changement d’état peut être gérer par l’objet lui-même ou par les états concrets.
Conséquences :- De nouveaux états peuvent être facilement ajoutés
- Les transitions d’état sont plus explicites
- Si les états concrets n’ont pas d’états internes (variables), alors ils peuvent être partagés (singleton)
Plus simple
![Page 86: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/86.jpg)
86
Stratégie : contexte
On utilise Stratégie lorsque :• De nombreuses classes associées ne diffèrent 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 données que les clients ne doivent pas
connaître.
![Page 87: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/87.jpg)
87
Stratègie : UML
Context
+ContextInterface()
Strategie
+Algorithme()
ConcreteStrategieA
+Algorithme()
+maStrategie
ConcreteStrategieB
+Algorithme()
Client
Context
+Op1()+Op2()+Op3()-SetEtat(Etat)
Etat
+Op1(): Etat+Op2(): Etat+Op3(): Etat
*
Etat1
+Op1(): Etat+Op2(): Etat
Etat2
+Op2(): Etat+Op3(): Etat
![Page 88: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/88.jpg)
88
Stratègie : Participants Les classes et/ou objets participant dans ce pattern sont:
•Strategie (SortStrategy) • Déclare une interface commune pour tous les algorithmes supportés.
•ConcreteStrategie (QuickSort, ShellSort, MergeSort) • Implémente un algorithme conformément à l’interface de la Strategie.
•Context (SortedList) • Est configuré avec un objet concreteStrategy• Maintient une référence sur un objet Strategy• Peut définir une interface qui permet à la stratégie d’accéder ses données.
![Page 89: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/89.jpg)
89
Stratègie : ExoRenvoyer• Celui qui gagne le plus• Celui qui prend le plus de vacances• Celui qui ……
public static void main(String[] args) {Entreprise e= new Entreprise();Employe trouve;e.Ajouter(new Employe ("Tchutchu" , 999999 , 0));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 : CastaVirer le plus cher : Tchutchu
Employe
~salaire: double~vacances: int~nom: String
<<create>>+Employe(nom: String, salaire: double, vacances: int)+getNom(): String+getSalaire(): double+getVacances(): int
Entreprise
~maStrategie: Strategie~lesEmployes: ArrayList = new ArrayList()
+setMaStrategie(maStrategie: Strategie)+Ajouter(e: Employe)+Rechercher(): Employe
*
![Page 90: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/90.jpg)
90
Patron de méthode : principe
• C’est du code (un algorithme cablé pour toutes les sous classes) qui est fait principalement par appel de méthodes virtuelles et abstraites.
• Ressemble à un template C++• Mécanismes très différents• Plus souple
• Les traitements peuvent diverger d’une sous classe à l’autre alors que cela est impossible avec les templates
• Plus simple• C’est du code en avance sur les futures sous-classes• Avantage : Découpe des méthodes en méthodes plus fines
![Page 91: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/91.jpg)
91
Patron de méthode : Exemple
TravaillerMatin();Dejeuner();TravaillerApresMidi();Loisir();Dormir();
Patron de méthode
vivre
If (age > 15)TravaillerMatin();
else Jouer();………….
Personneb
age : int
Dejeuner()<<{abstract}>> TravaillerMatin()<<{abstract}>> TravaillerApresMidi()<<{abstract}>> Loisir()Dormir()Jouer()<<abstract>> Vivre()
MiamMiam
RonRon
C’est drôle
![Page 92: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/92.jpg)
92
Patron de méthode
Personneb
age : int
Dejeuner()<<{abstract}>> TravaillerMatin()<<{abstract}>> TravaillerApresMidi()
<<{abstract}>> Loisir()Dormir()Jouer()
<<abstract>> Vivre()
Chirurgien
TravaillerMatin()TravaillerApresMidi()
Loisir()
Professeur
TravaillerMatin()TravaillerApresMidi()
Loisir()BlaBlater()
TravaillerMatin:Ouvrir();
TravaillerApresMidi:Fermer();
Loisir:Histoire grivoise
BlaBlater:BlaBla
TravaillerMatin: BlaBlater();
TravaillerApresMidi: BlaBlater();
Loisir: BlaBlater
![Page 93: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/93.jpg)
93
Patron de méthode
Personneb
age : int
Dejeuner()<<{abstract}>> TravaillerMatin()<<{abstract}>> TravaillerApresMidi()<<{abstract}>> Loisir()Dormir()Jouer()<<abstract>> Vivre()
Chirurgien
TravaillerMatin()TravaillerApresMidi()Loisir()
Professeur
TravaillerMatin()TravaillerApresMidi()Loisir()BlaBlater()
Chomeur
TravaillerMatin();Dejeuner();TravaillerApresMidi();Loisir();Dormir();
TravaillerMatin:Dormir();
TravaillerApresMidi:AllerANPE();
Loisir:Pleurer();
![Page 94: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/94.jpg)
94
Patron de méthode : Exo : Impôts
Nouvelle loi de finance :• Impôts 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• Célibataire Frais : -10 % IR = reste * 4/12
• Taxe d’habitation•Couple avec enfants : Un loyer moins 50 par enfants• Couple sans enfant : Deux loyers• Célibataire 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• Célibataire 20% de (ISF-80000) si > 100000 sinon 0
• Tout le monde profite d’un parachute (non golden) qui s’élève au max à 50% des revenus.• Un célibataire libéral paye un surplus d’impôt de 5000 indépendamment du parachute fiscal • TVA sociale augmente de 5 points
(Calcul sur le revenu annuel)
Déclaration : Revenu annuel-loyer mensuel-fortune-nombre d’enfants
![Page 95: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/95.jpg)
95
Patron de méthode : Exo : Impôts
Impots
Payer(revenu : double, loyer : double, isf : double, enfants : int = 0) : double<<abstract>> ImpotsRevenus(revenu : double, enfants : int = 0) : double<<abstract>> TaxeHabitation(loyer : double, enfants : int = 0) : double<<abstract>> ISF(isf : double) : double
ImpotsCoupleAvecEnfants
ImpotsRevenus()TaxeHabitation()ISF()
ImpotsCoupleSansEnfants
ImpotsRevenus()TaxeHabitation()ISF()
ImpotsCelibataire
ImpotsRevenus()TaxeHabitation()ISF()
ImpotsCelibataireLiberal
Payer()
![Page 96: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/96.jpg)
96
l’Observer : le contexte
• Problème : Définir une interdépendance de type (de classe) un à plusieurs, de façon telle que, quand un objet change d'état, tous ceux qui en dépendent en soit notifiés pour assumer leur propre mise à jour.
• Contexte : Ne pas présumer de l’identité des objets intéressés par l’événement (limitation du couplage). Ne pas présumer du nombre des intéressés
• Solution : Implantation d’une interaction entre objets de type souscription-diffusion
![Page 97: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/97.jpg)
97
l’Observer : la solution
• le Sujet : Définit un mécanisme général de gestion des objets en dépendance
• Maintient la liste des Observeurs à l ’aide des méthodes attach(Observer*) et detach(Observer *)
• Fournit le mécanisme permettant de prévenir les Observeurs lorsqu ’un changement d ’état se produit
• l ’Observeur : Définit l ’interface update() permettant d ’être prévenu d ’un changement d ’état
• le SujetConcret : Sous-classe de Sujet, gère 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
![Page 98: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/98.jpg)
98
l’Observer : UML
Observer<<Interface>>
+UpDate()
Sujet
+list<Observer> lesObserveurs
+add(Observer)+remove(Observer)+notify()
SujetConcret
+state
+getState(): state+setState(p): void
Observer1
+UpDate()
Observer2
+UpDate()
Réutilisable
Rmq : souvent UpDate contient des paramètres (evt, le sujet, l'état du sujet, …)
![Page 99: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/99.jpg)
99
l ’Observer : la dynamique
: Observer1 : SujetConcret : Observer2
add()
add()
setState()
notify()
UpDate()getState()
UpDate()remove()
setState()
notify()
UpDate()getState()
![Page 100: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/100.jpg)
100
Observer : Participants
Les classes et/ou objets participant dans ce pattern sont:• Sujet (Stock)
• Connaît les observateurs. Plusieurs observateurs peuvent observer un même sujet. Cela peut être dynamique.• Offre un moyen d’attacher et de détacher les observateurs.
• SujetConcret (IBM) • C’est lui qui contient l’information observable. • Prévient les observateurs quand l’information change.
• Observer (IInvestor) • C’est juste la définition de l’interface.
• les Observeri (Investor) • Garde une référence sur le Sujet concret • implémente l’interface de l’observer pour aller chercher l’information.
![Page 101: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/101.jpg)
101
Observer : Java
setChanged () {changed = true;}
NotifyObservers() {
if (changed) {
for each observer update();
changed = false;
}
Cela permet d'optimiser enn'appelant pas les observers àchaque changement d'état dusujet,mais seulement après unsetChanged().
import java.util.*; Observable
-changed: bool
+addObserver(Observer)+deleteObserver(Observer)+countObservers(): int+deleteObservers()+notifyObservers()#setChanged()
Observer<<interface>>
+update(Observable p1, Object p2)
![Page 102: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/102.jpg)
102
Observer : Java- Swing
Public class Exemple{JFrame cadre;
Public static main(){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 »}}
Dois-je le faire
NonOui
![Page 103: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/103.jpg)
103
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)
Main
+main(args: String)
Meteo.Calculer met température entre 0 et 20.Skieur.update va en vacances si la température est < 10° Nageur.update va en vacances si la température est >= 10°
Meteo m = new Meteo();Nageur n = new Nageur();Skieur s =new Skieur();m.addObserver(n);m.addObserver(s);m.calculer();m.setChanged();m.calculer();m.setChanged();m.calculer();m.setChanged();m.calculer();
le skieur va a la montagne : 8le nageur va a la mer : 12le skieur va a la montagne : 6
8
8
12
?
![Page 104: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/104.jpg)
104
Observer : Exercice2
![Page 105: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/105.jpg)
105
Visitor
• Rajouter une (ou plusieurs) méthode à un objet (sans la rajouter) !!!!
• A utiliser quand une classe ne sait pas ce qu’elle veut et qu’elle risque de vouloir beaucoup de choses.
• La classe fait déjà 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
![Page 106: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/106.jpg)
106
Visitor : UMLElement
<<interface>>
+Accept(Visiteur)
Visiteur<<interface>>
+Visit(Element)
ElementVisité
+Operation1()+Operation2()+Accept(Visiteur v)
VisiteurConcret1
+Visit(Element e)
Accept(Visiteur v){v.Visit(this);}
Visit (Element e){cast e->ElementVisitée.OPeration1()+ e.OPeration2();}
v1 : VisiteurConcret1 e : ElementVisité
<<create>>
<<create>>
Accept(v1): void
Visit(Element e): voida=Operation1()
b=Operation2()
a+b()
![Page 107: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/107.jpg)
107
Visiteur et l’objet Composite
Employees
Accept(visitor : Visitor*) : voidAttach(employee : Employee*) : voidDetach(employee : Employee*) : void
Employee
income : doublevacationDays : int
setIncome(value : double) : voidsetVacationDays(value : int) : voidAccept(visitor : Visitor*) : voidgetName() : stringEmployee(name : string, income : double, vacationDays : int) : EmployeesetName(value : string) : voidgetIncome() : doublegetVacationDays() : int
*
Iterator iter =employees.iterator();{
Employee e;while (iter.hasNext())
{ e =(Employee)iter.next(); e.Accept(visitor);}
}
RMQ : Il est possible d’explorer l’ensemble d’un composite avec un visiteur.Dans ce cas Employee et Employees ont tous les deux une méthode Accept etsont donc des Elements.
![Page 108: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/108.jpg)
108
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 supplémentaires• d'autres combinaisons TBD
![Page 109: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/109.jpg)
109
Visitor :correction
Main_1
+main(args: String)
IVisitor<<interface>>
~Visit(element: Element)
IncomeVisitor
+Visit(element: Element)
VacationVisitor
+Visit(element: Element)
Clerk
<<create>>+Clerk()
Director
<<create>>+Director()
President
<<create>>+President()
Element<<interface>>
+Accept(visitor: IVisitor)
Employee
-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)
Employees
-employees: ArrayList = new ArrayList()
+Attach(employee: Employee)+Detach(employee: Employee)+Accept(visitor: IVisitor)
*
![Page 110: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/110.jpg)
110
Mémento : UML
UnDo-ReDo
La classe à surveiller-----La mémoire----Le programme client (main)
Originator
-state
+SaveMemento(): Memento+RestoreMemento(m: Memento): void
Memento
-state
+GetState()+SetState()
Caretaker
+SetMemento(p Memento)+GetMemento(): Memento
-monMenento
1
RestoreMemento(m){state = m.GetState();}
SaveMemento(){m = new Memento();m.SetState(state);return m;}
SetMemento(p ){moMemento = p;}
GetMemento() : Memento{return monMemento;}
Client
![Page 111: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/111.jpg)
111
Mémento : Participants
•Memento • Stock l’état interne (tout ou partie) de l’objet Origine.• Il se protège contre les accès provenant d’autres objets que l’Originator. Les mementos ont en effet 2 interfaces. Le careTaker voit une interface simplifiée, il peut seulement passer le memento à d’autres objets. Au contraire l’originator voit une large interface, qui lui permet d’accéder a tous les champs.
•Originator • Crée un memento contenant une photo de lui même à 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
![Page 112: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/112.jpg)
112
Mémento : Exemple(1)import java.util.*;
// "Originator"
class SalesProspect{ private String name; private String phone; private double 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; }
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 ); }}
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; }}
![Page 113: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/113.jpg)
113
Mémento : 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();
}}
SalesProspect
nom : stringphone : stringbudget : int
GetNom() : stringGetPhone() : stringGetBudget() : intSetNom(p : string) : voidSetPhone(p : tring) : voidSetBudget(p : int) : voidSaveMemento() : MementoRestoreMemento(p : Memento) : voidAfficher() : void
<<originator>>
ProspectMemory
memento : Memento
GetMemento() : MementoSetMemento(p : Memento) : void
<<CareTaker>>
Memento
nom : stringphone : stringbuget : int
Memento(n, p, b)GetNom() : stringGetPhone() : stringGetBuget() : intSetNom(p : string) : voidSetPhone(p : string) : voidSetBudget(p : int) : void
11
![Page 114: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/114.jpg)
114
Memento : UML-Dynamique : Client : Caretaker : Originator : Memento
<<create>>
SaveMemento(): void
<<create>>
SetState(): void
rend le memento
SetMemento(p Memento): void
GetMemento(): void
RestoreMemento(m): voidGetState(): void
mis a jour de l'état()
![Page 115: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/115.jpg)
115
L’Itérateur-Iterator : le contexte
Balayer des collections
Problème, pas d'iterateur pour les tableaux, mais on peut
le développer
Enumeration<<interface>>
+hasMoreElements():boolean()+nextElement() :Object()
Iterator<<interface>>
+hasNext(): boolean+next(): Object+remove()
![Page 116: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/116.jpg)
116
Itérateur: UML
Aggregate
+CreateIterator(): Iterator
Iterator
+First(): Object+Next(): Object+IsDone(): boolean+CurrentItem(): Object
ConcreteAggregate
+CreateIterator(): Iterator
ConcreteIterator
-position
~ConcreteIterator(ConcreteAggragate)-maCollection
CreateIterator():return new ConcreteIterator(this);
Client
![Page 117: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/117.jpg)
117
Iterateur : ParticipantsLes classes et/ou objets participant dans ce pattern sont:
•Iterator • définit une interface pour accéder et traverser les éléments
d’une collection.•ConcreteIterator (Iterator)
• implémente l’interface Iterator. • garde trace de la position courante dans la collection.
•Aggregate (AbstractCollection) • définit une interface pour créer (obtenir) un objet Iterator.
•ConcreteAggregate (Collection) •Implémente l’interface de création et rend une instance d’un objet ConcreteIterator
![Page 118: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/118.jpg)
118
Itérateur : remarquesUn itérateur est dit robuste, s’il garantit que insertions et suppressions n’interféreront pas avec le parcours.Problème MultithreadDes opérations supplémentaires peuvent être utilisées : SauteA, Précédent…Une classe ne doit avoir qu'une seule responsabilité (au sens large)
sinon, il y a plus de risques de changement
Java 5 (generics)For (Object o : Collection)
{ o.fqq();}
J eu
+connecter()+quitter()+bouger()+feu()+pause()
Personne
+setNom()+setAdresse()+setNumeroTel()+enregistrer()+charger()
Telephone
+numeroter()+raccrocher()+parler()+clignoter()
DistributeurDeBonbons
+getNombre()+getEtat()+getPosition()
PaquetDeCartes
+hasNext()+next()+remove()+ajouterCarte()+retirerCarte()+battre()
Caddie
+ajouter(object)+retirer(object)+payer()
![Page 119: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/119.jpg)
119
Itérateur & Composite
• Itérateur interneOn peut balayer un composite en utilisant l'opération prévue (exempleGetCout()). Partir de la racine et simplement appeler la méthode
• Itérateur externeIl faut l'écrireMise en œuvre d'une pileUtiliser des iterator normaux pour les éléments composés
![Page 120: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/120.jpg)
120
Itérateur : Exercice
Reprendre l'ordinateur du Composite• Mettre les différents éléments dans des tableaux• Faire un iterateur de tableau• Faire un itérateur externe pour l'ensemble
![Page 121: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/121.jpg)
121
Chaîne de Responsabilité• Polymorphisme et récursivité• Utiliser la pattern Chaîne de responsabilité quand vous voulez donner à plus d’un objet une
chance de traiter une requête• L’ensemble des objets est construit dynamiquement
• Avantages :• Découple l’émetteur de la requête de ses récepteurs• Simplifie l’objet qui envoie la requête car, il n’a pas besoin de connaître la structure de
la hiérarchie utilisée, ni de conserver des références directes sur les membres.• Permet d’ajouter, modifier , supprimer des responsabilités en changeant la hiérarchie
• Exemples :• Machine à trier les pièces
•Traitement des mails• lettres de fan => PDG• réclamations => Service juridique• demandes de modification => R&D• publicité => Poubelle
![Page 122: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/122.jpg)
122
Chain of Resp : UML
Deux temps :• Configurer la hiérarchie• Faire des demandes
Client Handler
+HandleRequest()
ConcreteHandler
+HandleRequest()
-successor
0..1
Gere la request si possiblesinon successor.HandleRequest();
: Client Grouillot : ConcreteHandler successor : ConcreteHandler
HandleRequest()
[OK] [NOK] : HandleRequest()
[OK-NOK]
![Page 123: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/123.jpg)
123
Chain of Resp : Participants Les classes et/ou objets participant dans ce pattern sont:
•Handler (Approver) •définit une interface pour gérer les requêtes •(optionnel) implémente le lien successeur
•ConcreteHandler (Director, VicePresident, President) • Gère une requête si il en est responsable• Peut accéder à son successeur•Passe la requête à son successeur si il ne peut pas la traiter
•Client (ChainApp) •Provoque le premier appel de la requête vers un ConcreteHandler de la chaîne des successeurs.
![Page 124: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/124.jpg)
124
Chain of Resp : Exo
Président<100000
Vice-président<25000
Directeur<10000
Comité>=100000
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);
U
M
V
F Directeur
Acheter(p : Achat)
VicePresident
Acheter(p : Achat)
President
Acheter(p : Achat)
Approver
SetSuccesseur(p : *Approver)<<Abstract>> Acheter(p : Achat)
0..1+Chef
0..1
Achat
Prix : intlibelle : string
![Page 125: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/125.jpg)
125
Command• Faire faire qq chose à un objet sans le connaître• Commander qq chose sans connaître celui qui le fera• Réduction du couplage• Permet :
• les logs (historiques)• les undo-redo (avec ou sans Memento)• temporisation d'action• mise en file d'attente• contrôle• souvent utiliser avec un composite pour exécuter plusieurs
commandes (notion de macro commande)
![Page 126: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/126.jpg)
126
Command : UMLClient Invoker
Command
+Execute()
ConcreteCommand
+Execute()
Receiver
+Action() -receiver
receiver.Action()
: Client : ConcreteCommand a : Receiver : Command : Invoker
<<create>>
<<create>>
SetReceiver(a)
Execute
Execute(): voidAction(): void
Configurateur Utilisateur
![Page 127: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/127.jpg)
127
Command : Participants Les classes et/ou objets participant dans ce pattern sont:
• Command• définit une interface pour faire faire qq chose (Execute)
• ConcreteCommand • Connaît celui qui fait qq chose (Receiver)• Implémente la méthode Execute en faisant faire le travail au
receiver.• Receiver
• Fait le travail, il ne connaît personne• Client
• Connaît la ou les commandes concrètes et les initialisent avec un receiver.
• Invoker • Fait faire qq chose sans connaître ni les commandes concrètes ni les receivers (seulement l'interface)
![Page 128: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/128.jpg)
128
Command : Exo• Un architecte (client)• Chef de chantier (Invoker)• Plâtrier (Receiver)• Maçon (Receiver)• Couvreur (Receiver)• Couvreur véreux (Receiver)• Faire les murs externes (Action)• Faire les murs internes (Action)• Faire le toit (Action)• Faire des recettes (DeAction)• Construire (Command)
Je construis les murs extJe construis le toitJe casse le toitJe construis le toitJe casse le toitJe construis le toitJe construis les murs int
![Page 129: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/129.jpg)
129
Command : Correction
Architect
+Planifier()
Construire<<interface>>
+ConstruireElement()+Recetter(): boolean
ChefDeChantier
-taches: ArrayList = new ArrayList()
+Add(c: Construire)+Construire()
Couvreur
+FaireToit()+Recette(): boolean
CouvreurVerreux
-err: int = 3
+FaireToit()+Recette(): boolean
Macon
+FaireMur()+Recette(): boolean
Mur
-m: Macon
<<create>>+Mur(m: Macon)+ConstruireElement()+Recetter(): boolean
Toiture
-m: Couvreur
<<create>>+Toiture(m: Couvreur)+ConstruireElement()+Recetter(): boolean
Je construis les mursJe construis le toitJe casse le toitJe construis le toitJe casse le toitJe construis le toitJe construis les murs
![Page 130: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/130.jpg)
130
Interpreter : UML
Context
Client
AbstractExpression
+Interpret()
TerminalExpression NonterminalExpression
*
![Page 131: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/131.jpg)
131
Mediator : UMLMediator
ConcreteMediator
Colleague
+mediator
boutonbouton
listeliste
textAreatextArea
ControleurControleur
menumenu
Rmq :Façade-Observer
![Page 132: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/132.jpg)
132
Les Design patternsLe GoF
Structure
• Proxy : cacher la complexité d'un objet• Décorateur : Rajouter une responsabilité à une classe sans changer l'interface• Adaptateur : Adapter un objet à un autre• Composite : permet de traiter une structure d'objets de manière uniforme
(Des feuilles et des nœuds)• Façade : Représenter, regrouper et diriger un ensemble d'objets • Poids mouche : Partager de nombreux minis objets• Pont : permet de différencier une abstraction de son implémentation,
permettant à chacune d'évoluer indépendamment.
![Page 133: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/133.jpg)
133
Proxy :le contexte
On utilise un proxy :• pour référencer un objet par un moyen plus complexe qu'un "pointeur".• pour rajouter, modifier, supprimer des responsabilités à un objet sans en
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 très volumineux• Proxy de protection• Proxy de référence intelligente :
• Persistence• Comptage de référence
• ……….
![Page 134: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/134.jpg)
134
Proxy : UML
Proxy.Operation1() {fait qqchose…..leSujet.Operation1();}
Proxy.Proxy(Sujet param){leSujet = param;}
Sujet
+Operation1()
SujetReel
+Operation1()
Proxy
+Operation1()+Proxy(p: Sujet)
+leSujet
Client
![Page 135: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/135.jpg)
135
Proxy : Participants Les classes et/ou objets participant dans ce pattern sont:
•Proxy • remplace l’objet réel et pointe vers celui-ci • Operation1 fait le traitement suivant:
•Proxy distant : fabrique un message et l'envoie au Sujet réel via
un skeleton. Le proxy s'appelle alors un stub.• Proxy de protection : vérifie si l'appelant a les droits pour exécuter
l'opération, 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 chargée, alors il l'affiche.
•Proxy de référence intelligente : exemple smart pointer du C++
•Sujet •Définit l’interface commune au proxy et au sujet réel.
•SujetReel• Définit l’objet réel que le proxy représente.
![Page 136: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/136.jpg)
136
Proxy DistantRPCRMI
CORBA
DCOMWEBSERVICE
SujetReel
+Operation1()
Proxy
+Operation1()+Proxy(p: Sujet)
Sujet
+Operation1()
Client
Call
Stub skeleton
Send
CallRMIC
IDLInterfaceWSDL
![Page 137: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/137.jpg)
137
Proxy Distant :RMI (1)
Utilisation de rmi ( import java.rmi.* )• Créer une interface distante:
• public interface Sujet extends Remote• public void Operation1() throws RemoteException;• s'assurer que les paramètres et valeur de retour sont serialisable
• Créer une implémentation distante SujetReel• public class SujetReel extends UnicastRemoteObject implements Sujet• 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) {…}
![Page 138: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/138.jpg)
138
Proxy Distant :RMI (2)
• Générer le stub (proxy) et le skeleton• lancer rmic sur le fichier SujetReel.java• rmic SujetReel
• Exécuter rmiregistry (outil pour l'enregistrement) en tapant simplement dans une fenêtre dos rmiregistry
• Démarrer 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
![Page 139: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/139.jpg)
139
Proxy de protection :exercice (1)
Main
+main(args: String)
IEmploye<<interface>>
+Travailler()+Afficher()+getNom()+getSalaire()+setSalaire()
Employe
-nom: String-salaire: double-titre: String
<<create>>+Employe(nom: String, salaire: double, titre: String)+Travailler()+Afficher()+getNom(): String+getSalaire(): double+setSalaire(salaire: double)
ProxyPatron
-employe: Employe
<<create>>+ProxyPatron(employe: Employe)+Afficher()+getNom(): String+getSalaire(): double+setSalaire(salaire: double)+Travailler()
ProxyEmploye
-employe: Employe
<<create>>+ProxyEmploye(employe: Employe)+Afficher()+getNom(): String+getSalaire(): double+setSalaire(salaire: double)+Travailler()
![Page 140: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/140.jpg)
140
Proxy de protection :exercice (2)
![Page 141: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/141.jpg)
141
Proxy de protection avec InvocationHandler
BeanPersonne<<interface>>
~getNom(): String~getSexe(): String~getInterets(): String~getSexyOuNon(): int~setNom(nom: String)~setSexe(sexe: String)~setInterets(interets: String)~setSexyOuNon(note: int)
Moi même Les autres
getNom()
getSexe()
getInterest()
getSexyOuNon()
SetNom(String)
setSexe(String)
setInterest(String)
setSexyOuNon(int)
Rmq : setSexyOuNon () fait la moyenne des notes obtenues
getNom()
getSexe()
getInterest()
getSexyOuNon()
SetNom(String)
setSexe(String)
setInterest(String)
setSexyOuNon(int)
![Page 142: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/142.jpg)
142
Proxy de protection avec InvocationHandler
TestRencontres
~basedonnees: Hashtable = new Hashtable()
<<create>>+TestRencontres()+main(args: String)+tester()~getProxyProprietaire(personne: BeanPersonne): BeanPersonne~getProxyNonProprietaire(personne: BeanPersonne): BeanPersonne~getPersonneDepuisBD(nom: String): BeanPersonne~initialiserBD()
InvocationHandlerProprietaire
~personne: BeanPersonne
<<create>>+InvocationHandlerProprietaire(personne: BeanPersonne)+invoke(proxy: Object, method: Method, args: Object): Object
BeanPersonne<<interface>>
~getNom(): String~getSexe(): String~getInterets(): String~getSexyOuNon(): int~setNom(nom: String)~setSexe(sexe: String)~setInterets(interets: String)~setSexyOuNon(note: int)
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)
InvocationHandlerNonProprietaire
~personne: BeanPersonne
<<create>>+InvocationHandlerNonProprietaire(personne: BeanPersonne)+invoke(proxy: Object, method: Method, args: Object): Object
java.lang.reflect.InvocationHandler
![Page 143: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/143.jpg)
143
Méthode invoke de non Propriétaire
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();}
return null;}
![Page 144: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/144.jpg)
144
Méthode invoke de Propriétaire
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.printStackTrace();}
return null;}
![Page 145: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/145.jpg)
145
Proxy invocationHandler :Exercice(1)
Rmq basedonnees est une Hashtable----------------------------------------------Passage difficile :
![Page 146: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/146.jpg)
146
Proxy invocationHandler :Exercice(2)
![Page 147: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/147.jpg)
147
Decorator : Présentation
Problème : nombreux héritages
Solution : Héritage héritage + agrégation (poupée russe)
![Page 148: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/148.jpg)
148
Decorator :Le problème(1)
Nous allons revoir la façon dont on abuse généralement de l’héritage et vous allez apprendre comment « décorer » vos classes aumoment de l’exécution en utilisant une forme de composition.Pourquoi? Une fois que vous connaîtrez les techniques de décoration, vous pourrez affecter à vos objets (ou à ceux des autres) denouvelles responsabilités sans modifier le code des classes sous-jacentes.
Boisson
description
GetDescription()Cout()
Colombia
Cout() Sumatra
Cout()
Deca
Cout()
Espresso
Cout()
Boisson
description
GetDescription()Cout()
Colombia
Cout() Sumatra
Cout()
Deca
Cout()
Espresso
Cout()
ColombiaChocolat
Cout()
ColombiaVanille
Cout()
ColombiaChantillyChocolat
Cout()
DecaChantilly
Cout()
EspressoVanille
Cout()
RMQ :Le principe d’Ouverture (n’hésitez pas à étendre nos classes) et de Fermeture (Pas touche à mon code)
Un Deca avec du lait et du citron
![Page 149: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/149.jpg)
149
Decorator :Le problème(2)
Boisson
descriptionlaitvanillechocolat
GetDescription()Cout()SetLait()GetLait()SetVanille()GetVanille()
Colombia
Cout() Sumatra
Cout()
Deca
Cout()
Espresso
Cout()
Ecrire les méthodes Boisson::Cout etColombia::Cout
Boisson.Cout(){If GetLait() then cout += coutDuLaitIf GetVanille() then cout += coutVanille………………………………………….Return cout;}
Colombia::Cout (){Return 25+ super.Cout()}
Que se passe-t-il si on rajoute la crème Chantilly?Il faut modifier Boisson.Cout --- Pas touche à mon code
![Page 150: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/150.jpg)
150
Decorator : UML
Decorateuri.Operation():fait qq chosesuper.Operation()
Cela revient à rajouter une responsabilité à une classe mais sans en changer l'interface.Comparer avec le composite
Component
+Operation()
ComposantConcret
+Operation()+ComposantConcret()
Decorateur
+Operation()+Decorateur(Component)
-monComposant
1
Decorateur1
+Operation()+Decorateur1(Component)
Decorateur2
+Operation()+Decorateur2(Component)
ComposantConcret.Operation : fin de la chaîne
Decorateur.Operation() :monComposant.Operation()
![Page 151: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/151.jpg)
151
Decorator : la solution construction
Component
+Operation()
ComposantConcret
+Operation()
Decorateur
+Operation()
-monComposant
1
Decorateur1
+Operation()
Decorateur2
+Operation()
Deca
Lait
Citron
La boisson
Les ingrédients
Fabrication de l'objet :• Boisson b= new Deca();• b = new Lait(b);• b = new Citron (b);• b = new Citron(new Lait(new Deca()));
Un Deca avec du lait et du citron
De l'extérieure, on ne voitque le citron.
![Page 152: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/152.jpg)
152
Decorator : la solution
Un Deca avec du lait et du citron
Component
+Operation()
ComposantConcret
+Operation()
Decorateur
+Operation()
-monComposant
1
Decorateur1
+Operation()
Decorateur2
+Operation()
Deca
Lait
Citron
La boisson
Les ingrédients
Calcul du coût de la boisson :• citron = 0.2(Fait qq chose) +super.Operation
monComposant.Operation• lait = 0.3 (Fait qq chose) +super.Operation
monComposant.Operation• Deca = 0.5
Au retour Total = 1 €
![Page 153: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/153.jpg)
153
Decorator : Participants
Les classes et/ou objets participant dans ce pattern sont:•Component (Boisson)
• Définit l’interface pour les objets qui peuvent avoir des responsabilités ajoutées dynamiquement.
•ConcreteComponent (deca) • Définit un objet auquel on peut rajouter des responsabilités.
•Decorator (Ingredient) • Maintient une référence sur le component et définie une interface conforme conforme à celle du component.
•ConcreteDecorator (citron) • Ajoute les responsabilités au composant.
![Page 154: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/154.jpg)
154
Decorator : Exemple
On utilise l’héritage entre Ingrédient et boisson par Snobisme
Boisson::Cout est abstraiteColombia::Cout return 25 (le coût du Colombia sans ingrédientLait::Cout return le cout du Lait(10) + Le coût de maBoisson
Utilisation :Boisson b1 = new Colombia()b1.cout() => 25
Boisson b2 =new Colombia()b2 = new Lait(b2);b2.cout()=> 25 + 10
b2 = new Citron(b2); …..
Colombia
Lait
Colombia
Que se passe-t-il si on rajoute la crème Chantilly?Il faut rajouter la classe Chantilly
Colombia
Cout()
Sumatra
Cout()
Deca
Cout()
Espresso
Cout()
Boisson
description
GetDescription()Cout()
Ingredient
GetDescription()
11
Lait
Cout()Lait(p : Boisson)
Chocolat
Cout()Chocolat(p : Boisson)
Vanille
Cout()Vanille(p : Boisson)
+maBoisson
Citron
Lait
Colombia
![Page 155: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/155.jpg)
155
Decorator : Un mauvais exemple(1)
Book
Display() : voidBook(author : string, title : string, numCopies : int) : Book
Video
playTime : int
Display() : voidVideo(director : string, title : string, numCopies : int, playTime : int) : Video
Decorator
Display() : voidDecorator(libraryItem : LibraryItem*) : Decorator
LibraryItem
numCopies : int
getNumCopies() : intsetNumCopies(v : int) : voidDisplay() : void
#libraryItem
0..1
1
0..1
1
Borrowable
Display() : voidBorrowable(libraryItem : LibraryItem*) : BorrowableBorrowItem(name : string) : voidReturnItem(name : string) : void
![Page 156: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/156.jpg)
156
Decorator : un mauvais exemple (2)
![Page 157: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/157.jpg)
157
Decorator : ExerciceSoldat
+bagarrer(): int+getVie(): int+setVie(p: int)
Decorator
+getVie(): int+setVie(p: int)+bagarrer(): int
SoldatNu
+vie: int
+bagarrer(): int+getVie(): int+setVie(p: int)+SoldatNu()
SoldatAvecEpee
+bagarrer(): int+SoldatAvecEpee(p: Soldat)
+component
SoldatPatient
+bagarrer(): int+SoldatPatient(p: Soldat)
SoldatAvecFusil
+bagarrer(): int+SoldatAvecFusil(p: Soldat)
![Page 158: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/158.jpg)
158
l ’Adaptateur : le contexteObjectif :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 particulièrement adapté lorsque les conditions suivantes sont remplies :
• On veut utiliser une classe existante dont l'interface ne coïncide pas avec celle escomptée
• On souhaite créer une classe qui puisse être accédée par des interfaces diverses
• Récupération de vieilleries
• Façade
![Page 159: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/159.jpg)
159
l ’Adaptateur : Uml et Exemple
Dentiste
+Travailler()
Boulanger
+Travailler()
Travailleur<<interface>>
+Travailler()
Chomeur
+ChercherDuTravail()
SarkoChomeur
+Travailler() +monChomeur
monChomeur.ChercherDuTravail
Chomeur
+ChercherDuTravail()
super.ChercherDuTravail
Client Cible
+fqq()
Adapteur
+fqq()
Adapté
+fac()
Adapteur.fqq()=Adapté.fac()
![Page 160: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/160.jpg)
160
L'adaptateur : Participants
Les classes et/ou objets participant dans ce pattern sont: • Cible
• Définit ce qui est appelé par le client •Adapteur
• Fait le lien entre ce que veut le client et ce qui existe vraiment•Adapté
• C’est ce qui existe vraiment (récupération) •Client
• Ne connaît que l’interface de la cible.
![Page 161: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/161.jpg)
161
L'adaptateur : Exercice
Cancaneur
+Cancaner()
Cacardeur
+Cacarder()
Canard
Leurre
CanardPlastique
Oie
+Cacarder()
Canard.Cancaner "Coincoin"Leurre.Cancaner "Silence"CanardPlastique "Pchiff"Oie.Cacarder " CoincoinCoincoin "
Pb : Faire cancaner une troupe de Cancaneur contenant des oies
![Page 162: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/162.jpg)
162
Composite : Le contexte & UMLOn utilise le Composite lorsque on veut :• Représenter une hiérarchie d'objets• Ignorer la différence entre un composant simple et un composant
en contenant d'autres (interface uniforme)
Client Component
+Operation()
Composite
+Operation()+Add(p: Component)+Remove(p: Component)+GetChild(index: int): Component
Leaf
+Operation()
+lesEnfants*
Operation()pour chaque enfant :Faire Operation()puis faire qq chose sibesoin pour le composite
Comparer avec le décorateur
![Page 163: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/163.jpg)
163
Composite : Participants
•Component (Equipement) • Déclare l’interface pour les objets de la composition.
•Leaf (Peripherique) • Représente les objets feuilles (sans enfants) de la composition.• Définit le comportement de ces objets.
•Composite (Container) • Définit le comportement des objets ayant des enfants.• Range, stocke les composants enfants
•Client (pg main) • Manipule les objets comme un seul en s’appuyant sur l’interface 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
![Page 164: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/164.jpg)
164
Composite : Exercice
Ordi IBM
TourDVD
HDCartemère
ModemAdsl
Carte mérePentium
Ventilo
// ConfigurationPeripherique 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 mère");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);// UtilisationSystem.out.println( "le prix total est de : " + ordi.GetPrix() );
CompositeLeaf
![Page 165: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/165.jpg)
165
Composite : Solution
EquipementSimple
puissance : intprix : int
GetPuissance()GetPrix()Ajouter()EquipementSimple()
Peripherique
Peripherique()
Container
Container()
TourDeLuxe
prix : int
GetPrix()TourDeLuxe()
Equipement
GetPuissance()GetPrix()Ajouter()GetNom()Equipement()
EquipementCompose
GetPuissance()GetPrix()Ajouter()EquipementCompose()
**
![Page 166: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/166.jpg)
166
Façade : UML
![Page 167: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/167.jpg)
167
La Façade : le contexteProblème :
La conception objet implique la décomposition de chaque système complexe en collection d’objets collaborant.
On veut limiter le couplage des utilisateurs du système avec les éléments de cette décomposition.
On veut garder la possibilité pour certains client de manipuler l’intérieur du système.
Solution : On créé un nouvel objet servant de façade à un type d’utilisateur donné et lui offrant des services de haut niveau.
![Page 168: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/168.jpg)
168
La Façade : les bénéfices
Conséquences :Découplage d’une partie des clients avec le système considéré. Réduction du nombre de classes (complexité) à prendre en compte pour ce client Réduction des dépendances à la compilation
Certains langages (C++ avec les NameSpaces, java avec les packages) permettent de cacher une partie des classes d’un sous-système.-> Encapsulation au niveau des systèmes
![Page 169: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/169.jpg)
169
Façade : Participants
Les classes et/ou objets participant dans ce pattern sont: •Façade (Prêt)
•Connaît les classes du sous système qui sont responsables dechaque requête.
•Transmet les requêtes aux classes adéquat.•Subsystem classes (VerifApport, VerifSalaire, VerifCaution)
• Implémentent les fonctionnalités du sous système.• Ne connaissent pas la façade
Exemple : Transformation d'une liste en pile
![Page 170: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/170.jpg)
170
Façade : Exo
VerifApport
~apport: double~pret: double
<<create>>+VerifApport(apport: double, pret: double)+Verif(): boolean
VerifSalaire
~salaire: double~pret: double
<<create>>+VerifSalaire(salaire: double, pret: double)+Verif(): boolean
VerifCaution
~caution: double~pret: double
<<create>>+VerifCaution(caution: double, pret: double)+Verif(): boolean
• Apport est au moins de 10% du prêt• Prêt <= 250 fois le salaire• Caution >= à 50% du prêt
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));
trueRefus caution trop faiblefalseRefus salaire trop faibleRefus caution trop faibleRefus apport trop faiblefalse
Prêt, salaire, apport, caution
Prêt, salaire, apport, caution
![Page 171: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/171.jpg)
171
Flyweight : Poids mouche :UML
Utilisation : beaucoup de petits objets à se partager à plusieurs.Exemple : les caractères d'un document
PluriGleton
FabriqueDePoidsMouche
+GetFlyweight(key)
PoidsMouche
+Operation()
Client
PoidsMoucheConcret PoidsMouchePartagé
+lesPoids
*
![Page 172: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/172.jpg)
172
Poids mouche : Exemple : une forêtArbre
-x: int-y: int
+Afficher(): void
GestionnaireArbre
+TableauXY
+Afficher(): void
ArbrePoidsMouche<<singleton>>
+Afficher(x: int, y: int): void
: Arbre
: Arbre
: Arbre
: Arbre
: Arbre
• Avantages :• Réduit le nb d'instances• Economise la mémoire
• Rmq :tous les arbres doiventêtre gérés de la même manière
![Page 173: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/173.jpg)
173
Bridge : UML
Rmq : ressemble au state
![Page 174: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/174.jpg)
174
Bridge : Exemple#include <iostream>using namespace std;
// .hclass 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() ;};
// .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;}
int main() { Abstraction *ab = new RefinedAbstraction(); ab->SetImplementor( new ConcreteImplementorA()); ab->Operation(); ab->SetImplementor(new ConcreteImplementorB()); ab->Operation(); }
![Page 175: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/175.jpg)
175
Les Design patternsLe GoF
Création
• Singleton : un et un seul objet visible par tous• Fabrication : créer un objet en fonction d'un paramètre• Fabrique abstraite : créer une famille d'objets tous cohérents• Monteur : construire un objet en différentes étapes • Prototype : permet de spécifier le type d'objets à créer en utilisant une
instance prototype. Le prototype sera copié pour créer les nouveaux objets.
![Page 176: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/176.jpg)
176
Problème : Une classe nécessite de n’être instanciée qu’une seule fois dans une application
Contexte : Cette instance unique est utilisable à plusieurs endroits dans l ’application.
Solution : On va confier à la classe elle-même la responsabilité d’assurer l’unicité de son instance.
Le singleton
![Page 177: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/177.jpg)
177
Le singleton uml
ClasseSingleton
<<static>> uniqueInstancedonnéeInstance
<<static>> Instance()OpérationSingleton()
Instance() { retourne uniqueInstance}
![Page 178: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/178.jpg)
178
Amélioration du singleton
L'usine à singleton : Remplacer singletons par singleton
Rmq : En C++, mettre en private le constructeur de copie et l'opérateur d'affectation
Rmq : En multi thread, utiliser un mutex ou synchronized.
![Page 179: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/179.jpg)
179
Fabrication : Présentation
Le problème :If cas1 alors return new c1();If cas2 alors return new c2();If cas3 alors return new c3();
Problème de dépendance, ce sous programme dépend de c1,c2,c3….Et ce problème arrive à chaque fois que l'on veut créer un des ces objets.C'est du code Beurgh!
La fabrication va garder et prendre en charge ce code Beurgh, au moinsIl sera à un seul endroit.
Règle POO :Remplacer le switch par le polymorphisme
Fabrication :Garder le switch ce qui évitera de faire des New (et des dépendances)
![Page 180: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/180.jpg)
180
Fabrication : Problème de dépendance
C1 C2 C3
SousProgramme
C1 C2 C3
C<<interface>>
Fabrication
• La fabrication va permettre l'inversion des dépendances• on va encapsuler la création des objets dans une fabrique• on peut créer plusieurs objets, mais ils sont indépendants les uns
des autres
![Page 181: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/181.jpg)
181
Fabrication : exemple les pizzerias(1)
FabriqueDePizzasBrest
~creerPizza(item: String): Pizza
FabriqueDePizzasStrasbourg
~creerPizza(item: String): Pizza
Pizza
~nom: String~pate: String~sauce: String~garnitures: ArrayList = new ArrayList()
~preparer()~cuire()~couper()~emballer()+getNom(): String+toString(): String
PizzaPoivronsStyleStrasbourg
<<create>>+PizzaPoivronsStyleStrasbourg()~couper()
PizzaVegetarienneStyleBrest
<<create>>+PizzaVegetarienneStyleBrest()
PizzaVegetarienneStyleStrasbourg
<<create>>+PizzaVegetarienneStyleStrasbourg()~couper()
Pizzeria
~creerPizza(item: String): Pizza+commanderPizza(type: String): Pizza
TestPizzeria
+main(args: String)
L'usine
Les produits
![Page 182: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/182.jpg)
182
Fabrication : exemple les pizzerias(2)
celleDeBrest : Pizzeria
brest-fromage : Pizza
commanderPizza(type: String): pizza
creerPizza(item: String): pizza
preparer(): void
cuire(): void
couper(): void
emballer(): void
[B]
Pizza creerPizza(String item) if (item.equals("fromage")) { return new PizzaFromageStyleBrest();} else if……
Pizzeria fabriqueBrest = new FabriqueDePizzasBrest(); [A] Pizza pizza = fabriqueBrest.commanderPizza( "fromage" ); [B]System.out.println("Luc a commandé une " + pizza.getNom() + "\n");qq
[A]
![Page 183: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/183.jpg)
183
Fabrication : le Design pattern
Createur
+Fabrication(type: String): Produit+uneOperation()
CreateurConcret
+Fabrication(type: String): Produit
ProduitConcret1
+fqq()
ProduitConcret2
+fqq()
Produit
+fqq()
Client
![Page 184: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/184.jpg)
184
Fabrication : Participants
Les classes et/ou objets participant dans ce pattern sont: • Produit (Page)
•Définie l’interface des objets créés par la fabrication (Afficher)
• ProduitConcreti (Introduction,Plan,Conclusion,Dev) • implementent l’interface du produit (CreatePages)
• Createur (Document) •Déclare la méthode "Fabrication(String) : Produit" qui rend un objet de type Produit.
• CreateurConcret (Report, Resume) • Surcharge la méthode Fabrication pour rendre une instance du produit concret. C'est le code Beurgh!!!• Rmq :la méthode peut ne pas avoir de paramètre, dans ce cas le code n'est pas beurgh.
![Page 185: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/185.jpg)
185
Fabrication exerciceFabriqueLe produit
Page<<interface>>
+Afficher(): void
Introduction
+Afficher(): void
Conclusion
+Afficher(): void
Fabrique<<interface>>
+CreerPage(String: type): Page
FabriqueConcrete
+CreerPage(String: type): Page
Client
FabriquePage fab = new FabriquePage();
Page i = fab.CreatePage("Intro");
i.Afficher();
i=fab.CreatePage("Conclusion");
i.Afficher();
![Page 186: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/186.jpg)
186
Fabrication Abstraite : motivation
Application
IHMMotif
IHMwindows
Application IHM
IHMMotif
IHMwindows
L ’application utilise IHM sans savoir si ils ’agit de Motif ou bien de Windows
![Page 187: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/187.jpg)
187
Fabrication Abstraite : Structure
FabriqueAbstraite
CreerProduitA()CreerProduitB()
FabriqueConcrete1
CreerProduitA()CreerProduitB()
FabriqueConcrete2
CreerProduitA()CreerProduitB()
ProduitAbstraitA
ProduitAbstraitB
ProduitA1 ProduitA2
ProduitB1 ProduitB2
Application
<<instancie>>
![Page 188: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/188.jpg)
188
Fabrication Abstraite : Constituants
• FabriqueAbstraite (Facultative) • Déclare une interface contenant les opérations de création d ’objets produits
abstraits• Fabrique concrète
• Implémente les opérations de création d ’objets produits concrets• Produit Abstrait (Facultatif)
• Déclare une interface pour un type d ’objet produit• Produit concret
• Définit un objet produit qui doit être crée par la fabrication concrète correspondante
• Implémente l ’interface de ProduitAbstrait• Application
• n’utilise que les interfaces déclarées par les classes FabriqueAbstraite etProduitAbstrait
![Page 189: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/189.jpg)
189
Fabrique Abstraite : Avantages et inconvénients
• Isoler les classes concrètes• Faciliter la substitution d ’une famille de produits• Favoriser le maintien de la cohérence entre les objets• Gérer de nouveaux types de produits est complexe• Ne facilite pas la lisibilité
FabriqueAbstraite
CreerProduitA()CreerProduitB()
![Page 190: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/190.jpg)
190
Builder-Monteur
Rmq : Le monteur (Builder) est utilisé pour construire différentes sortes d’objets selon une certaine méthodologie (étapes par étapes). Chaque étape dépend du type de l’objet, mais la succession des étapes en est indépendante. (comparer avec le patron de méthode)
On utilise le buider lorsque :• L'algorithme pour créer un objet doit être indépendant des parties qui
le composent et de la façon de les assembler.• Le processus de construction permet différentes représentations de
l'objet construit.
![Page 191: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/191.jpg)
191
Builder : UMLDirector
+Construct(Builder)
Builder
+BuildPart1()+BuildPart2()
ConcreteBuilder
+BuildPart1()+BuildPart2()+GetResultt(): Product
Product
+list<Parties> leProduct
+builder
BuildPart1()BuildPart2();GetResult();
: Director b1 : ConcreteBuilder
<<create>>
Construct(Builder): void
BuildPart1(): void
BuildPart2(): void
GetResultt(): void
![Page 192: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/192.jpg)
192
Builder : ParticipantsLes classes et/ou objets participant dans ce pattern sont:
•Builder (VehicleBuilder) • Spécifie une interface pour identifier les étapes de la création d’un produit.
•ConcreteBuilder (MotorCycleBuilder, CarBuilder, ScooterBuilder) • Construit et assemble les différentes parties d’un objet en implémentant
l’interface du Builder. • Définit le produit final et permet de le retrouver.
•Director (Shop) • C’est le client (celui qui utilise le builder).
•Product (Vehicle) • Représente le ou les produits fabriqués
![Page 193: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/193.jpg)
193
Builder : Exemple
voici la partie A du produit1voici la partie B du produit1voici la partie A du produit2voici la partie B du produit2
Builder
+BuildPart1()+BuildPart2()+GetResult(): Product1
Director
+Construct(Builder)
+builder
ConcreteBuilder1
-leProduit: Product1
<<create>>+ConcreteBuilder1()+buildPartA()+buildPartB()+getResult(): Product1
ConcreteBuilder2
-leProduit: Product1
<<create>>+ConcreteBuilder2()+buildPartA()+buildPartB()+getResult(): Product1
Product
~leProduit: ArrayList = new ArrayList()
+add(s: String)+show()
![Page 194: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/194.jpg)
194
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 : Stringmoteur : Stringroue : Stringporte : String
Show() : void
VehiculeBuilder
GetVehicule() : VehiculeBuildMoteur() : voidBuildRoue() : void
BuildPorte() : void
1
#vehicule
1
MotoBuilder
BuildMoteur() : voidBuildRoue() : voidBuildPorte() : voidMotoBuilder()
VoitureBuilder
BuildMoteur() : voidBuildRoue() : voidBuildPorte() : voidVoiturBuilder()
Shop
Construire(p : VehiculeBuilder) : void
![Page 195: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/195.jpg)
195
Prototype• Masque au client les complexités de la création de nouvelles instances
•(new, clone, deserialisation, …)• Permet au client de générer des objets dont le type n’est pas connu.• Dans certaines circonstances, la copie d’un objet peut être plus efficace
que la création d’un objet (memberWiseClone du c#)
![Page 196: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/196.jpg)
196
Prototype : Participants
Les classes et/ou objets participant dans ce pattern sont:•Prototype
• Déclare une interface pour se cloner•ConcretePrototype
• Implémente une opération pour se cloner•Client
• Créé un nouvel objet en demandant au prototype de se cloner.
![Page 197: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/197.jpg)
197
DP : Exercice général(1)
Les stagiaires ont un nom, un sexe et une catégorie (TM, M, Moyen, B , TB). Ils font des exos qui sont réussis en fonction de leur état (TM =4-10, M=5-10, B=10-15, TB=15-20,Moyen =11)Le prof note aléatoirement (presque) les exos mais favorise les filles. (note en fonction de l’état, plus ou moins un nombre compris entre –10 et + 8, rajouter 2 points pour les filles (sauf pour les très bonnes), la note finale est comprise entre 0-20. Quand un élève obtient une note < 7 son état se dégrade, alors que si il obtient une note > 13 son état s’améliore. Le chef vire celui ou celle qui a la plus mauvaise note à chaque exercice.Bill Gates débauche 2 fois le ou la meilleure, tandis que Google n’en débauche qu’un ou qu’une.D’autres personnes, entreprises ou organismes quelconques pourront bientôt s’ intéresser aux stagiaires.Toutes les notes sont sauvegardées pour chaque élève.
Singleton
State
Observer
Strategie
Template methode
memento
Singleton
State
Observer
Strategie
Template methode
memento
![Page 198: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/198.jpg)
198
DP : Exercice général(1)
LeNul
Tester()InitNote()$GetInstance()
-$instance
1
0..1
1
0..1
LeMeilleur
Tester()InitNote()$GetInstance()
-$instance
1
0..1
1
0..1
Strategie
note : int
Rechercher()Tester()InitNote()
Etat
Exercice(p : Stagiaire*) : intGetEtat() : stringEtat(n : string) : Etat
EtatTM
Exercice()EtatTM()$GetInstance()
1
0..1
1
0..1
EtatB
Exercice()EtatB()$GetInstance()
1
0..1
1
0..1
Entreprise
Update() : voidEntreprise(n : string) : EntrepriseDebaucher() : void
Observer
Update()
Personne
Update() : voidVirer() : voidPersonne(n : string) : Personne
Sujet
Notify()Attach()Dettach()
Memento
note : int
Memento(n : string, : int) : Memento$AfficherLesResultats() : voidAfficher() : void
Stagiaire
sexe : bool = (s)
Exercice() : intStagiaire(n : string, s : bool, etat : Etat*) : StagiaireAfficher() : voidSetState(p : Etat*) : voidGetSexe() : boolGetNote() : intGetNom() : stringSaveMemento() : void
0..11
-state
0..11
LaClasse
Exercice() : voidAjouterStagiaire(p : Stagiaire*) : voidAfficher() : void$GetInstance() : LaClasse*Rechercher(s : Strategie*) : string
1
0..1
1
-$instance0..1
![Page 199: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/199.jpg)
199
DP : Exercice général(2) Appelant
+cancaner()
CanardEnPlastique
+cancaner()
Colvert
+cancaner()
Leurre
+cancaner()
Mandarin
+cancaner()
SimulateurDeCanards
+main(args: String)~simuler()~simuler(canard: Cancaneur)
Cancaneur
• Traiter le cas des oies• Compter les coinscoins• Comment être sûr de compter tout le monde ?• Faire cancaner toute une troupe• Observer de temps en temps et en temps réel le couac de chaque canard
Oie
+cacarder()
Adaptateur
Decorateur
Fabrique abstraite
Composite
Observer
Adaptateur
Decorateur
Fabrique abstraite
Composite
Observer
![Page 200: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/200.jpg)
200
Autres Patterns
Les classes d'analyse
Le raii
![Page 201: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/201.jpg)
201
Les classes d'analyse• Les trois axes d'une classe :
• Boundery - Frontière - Vue• Contrôleur• Entity - Objets métier - modèle
a1
a2
uc1
uc2
uc3
a3
vue1
vue2
vue3
c1
c2
c3
protocole
e1
e2
e3
e4
uc1<<useCaseRealization>>
uc1
vue1 c1
e1 e2m1m2
m3
Vopc
a1
vue1 c1
![Page 202: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/202.jpg)
202
RAII : Présentation du pb
out
Tout s’est mal passé et en plusOn ne libère pas les ressourcesTout s’est mal passé et en plusOn ne libère pas les ressources
![Page 203: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/203.jpg)
203
(RAII) à la sauce Java (Finally)
![Page 204: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/204.jpg)
204
RAII à la sauce C++Selon l'approche RAII, on peut modifier la classe Datafile pour qu'elle fasse le Open() dans son constructeur (avec levée d'exception), et le Close() dans son destructeur.Puis l'on crée une petite classe utilitaire DBLock qui gère le verrouillage de la base :
![Page 205: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/205.jpg)
205
Patterns et architecture
MVC
FrameWork
Organisation des packages
Métriques
![Page 206: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/206.jpg)
206
Patterns et architecture
MVC
FrameWork
Organisation des packages
Métriques
![Page 207: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/207.jpg)
207
Vue
Controleur
Modele
1 2
3
4
5
(Origine :SmallTalk-Xerox) 1. L'utilisateur a fait qq chose (bouton, menu, ….)2. Le contrôleur prévient le modèle3. Modification d'IHM (bouton non disponible, menu grisé, …)4. Le modèle prévient la vue que qq chose est arrivé (changement d'état – Notify)5. La vue demande des informations complémentairesCela permet d'avoir plusieurs vues, plusieurs modèles
MVC
![Page 208: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/208.jpg)
208
Vue
Controleur
ModeleComposite
Stratégie/etat
SujetObserver UpDate()
laVue Strategie
ctrl1
+PushButton()
Ctrl2
+ClickMenu()
MVC : Design pattern composé
![Page 209: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/209.jpg)
209
VueDos VueSwing
-composite
Vue
+Update()
ObjetMetier
Configuration
-fabrique-abstraite
Utilisable
Gerable
Controleur
-state-strategie
Sujet
+Attach(o: Vue)+Detach(o: Vue)+Notify()
UtilisableGerable
Utilisateur
Utiliser
Admin
Gerer
Systeme
-Configurer+Utiliser
Util Conf
ConfigurerUtiliser
Util Conf
ConfigurerUtiliser
LeCtrl
utilisable gerable
Lecture
UneVue
MVC
![Page 210: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/210.jpg)
210
Framework : Introduction
Définition : Un framework est une infrastructure logicielle qui facilite la conception des applications par l'utilisation de bibliothèques de classes ou de générateurs de programmes, soit dit en quelques mots : un cadre de développement.
Exemples:•Struts est un framework java d'interfaçage homme machine pour applications
web.•SWING est un framework java d'interfaçage homme machine pour une
application fenêtrée.• Les MFC sont un framework C++ d'interfaçage d'une application avec le
système d'exploitation windows.• la GTK est un framework C d'interfaçage homme machine avec une
application fenêtrée, conçu à l'origine pour les systèmes unix et porté sur windows.
• java est un framework, Dot.net aussi, Junit est un framework de test ….
![Page 211: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/211.jpg)
211
Framework : Utilisation
•Il existe des frameworks de divers types, et ceux-ci sont complémentaires• un framework réunit l'ensemble des implémentations récurrentes de nos
développements. Les avantages en sont :• éviter de recoder encore et toujours les mêmes bouts de codes rébarbatifs,• agir en un point unique pour modifier l'ensemble du comportement
applicatif (Par exemple le "look and feel") faisant profiter toutes les applications des avancées du framework,
• assurer la robustesse de ces parties du code (répétitives et essentielles).
•Exemple Spring : Java JEE est trop compliqué(pas d'héritage et de polymorphisme avecLes EJB.
• Struts pour la présentation• Hibernate pour la persistance
![Page 212: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/212.jpg)
212
Composant
Un composant est formé avec:• Une interface définissant la structure objet nécessaire à la réalisation d'un
travail (ou plusieurs)• son implémentation.
Réunir un ensemble des classes et des interfaces ayant des comportements agissant dans le même sens au sein de composants.
Les divers composants communiquent par le biais d'une Façade.
![Page 213: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/213.jpg)
213
Organisation des packages
K
L
A B
I
E
J
G
D
H
C
F
![Page 214: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/214.jpg)
214
Organisation des packages
A
Op1()Fqq()
(f rom PA)
B
Op2()Fqq()
(f rom PB)+monB+monAOp1{b.Fqq()}
Op2{a.Fqq()}
monA : A : Application : A monB : B
Op1( )
Fqq( )
Op2( )
Fqq( )
![Page 215: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/215.jpg)
215
Dépendances cycliques : Interface
FqqAble
Fqq()
(f rom Interf ace)
<<Interface>>
A
Op1()Fqq()AddmonB(p : FqqAble)
(from PA)
+monB
Application
B
Op2()Fqq()AddMonA(p : FqqAble)
(from PB)
+monA
L'application :• Crée un objet A• Crée un objet B• Présente B à A en tant
que FqqAble• Présente A à B en tant
que FqqAble
![Page 216: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/216.jpg)
216
Métriques (1)· Lines of Code (LOC): Le nombre total de lignes de code. Les lignes blanches et les commentaires ne sont pas comptabilisés· Number of Static Methods (NSM): Le nombre de méthodes statiques dans
l'élément sélectionné.· Afferent Coupling (CA): Le nombre de classes hors d'une package qui dépendent
d'une classe dans le package· Normalized Distance (RMD): RMA + RMI - 1: Ce nombre devrait être petit, proche
de zéro pour indiquer une bonne conception des parquets.· Number of Classes (NOC): Le nombre de classes dans l'élément sélectionné.· Specialization Index (SIX): NORM * DIT / NOM: Moyenne de l'index de spécialisation.· Instability (RMI): CE / (CA + CE) : Ce nombre vous donnera l'instabilité de votre projet.
C'est-à-dire les dépendances entre les paquets.· Number of Attributes (NOF): Le nombre de variables dans l'élément sélectionné.· Number of Packages (NOP): Le nombre de packages dans l'élément sélectionné.· Method Lines of Code (MLOC): Le nombre total de lignes de codes dans les méthodes.
Les lignes blanches et les commentaires ne sont pas comptabilisés· Weighted Methods per Class (WMC): La somme de la complexité cyclomatique de
McCabe pour toutes les méthodes de la classe.· Number of Overridden Methods (NORM): Le nombre de méthodes redéfinies.· Number of Static Attributes (NSF): Le nombre de variables statique.· Nested Block Depth (NBD): La profondeur du code
![Page 217: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/217.jpg)
217
Métriques (2)· Number of Methods (NOM): Le nombre de méthodes .· Lack of Cohesion of Methods (LCOM): Une mesure de la cohésion d'une classe. Plus le
nombre est petit et plus la classe est cohérente, un nombre proche de un indique que la classe pourrait être découpée en sous-classe. Néanmoins, dans le cas de Javabean, cette métrique n'est pas très correcte, car les getteurs et les settteurs sont utilisés comme seules méthodes d'accès aux attributs. Le résultat est calculé avec la méthode d' Henderson-Sellers : on prend m(A), le nombre de méthodes accédant à un attribut A, on calcule la moyenne de m(A) pour tous les attributs, on soustrait le nombre de méthodes m et on divise par (1-m).
· McCabe Cyclomatic Complexity (VG): La complexité cyclomatique d'une méthode. C'est-à-dire le nombre de chemins possibles à l'intérieur d'une méthode, le nombre de chemin est incrémenté par chaque boucle, condition, opérateur ternaire, # Il ne faut pas que ce nombre soit trop grand pour ne pas compliquer les tests et la compréhensibilité de la méthode.
· Number of Parameters (PAR): Le nombre de paramètres.· Abstractness (RMA): Le nombre de classes abstraites et d'interfaces divisés 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 dépendent d'une
classe d'un autre package.
![Page 218: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/218.jpg)
218
Métriques (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 hiérarchie
d'héritage.
Graphe de dépendances entre packages
http://metrics.sourceforge.net/update
![Page 219: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/219.jpg)
219
Bibliographie
Valtech : • Management Agile
• Christophe Addinquy (27mn)• David Gageot (17 mn)
• Xp ca marche vraiment ? (régis Medina –18mn)
TV4IT : • Eric Groise• Michel Cara
Vidéo Google : DP & Python : http://www.aleax.it/goo_pydp.pdf (2h)Alex Martelli
![Page 220: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/220.jpg)
220
Table des matièresLes patterns Grass 5Principes fondamentaux de conception 14Processus objet (up-xp) 32Processus objet (test-refactoring) 52______________________________________Les design patterns 70Les design patterns de comportement 75Automate 76Stratégie 86Patron de méthode 90Observeur 96Visiteur 105Memento 110Iterateur 115Chaîne de responsabilité 121Commande 125Interpréteur 130Médiateur 131Les design patterns de structure 132Proxy 133Decorateur 147Adaptateur 158Composite 162Façade 167Poids mouche 171Pont 173
Les designs patterns de création 175Singleton 176Fabrication 179Fabrication abstraite 186Builder 190Prototype 195_______________________________________Autres Patterns 200Les classes d'analyse 201Raii 202Patterns et architecture 205MVC 207Métriques 216Bibliographie 219
![Page 221: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/221.jpg)
221
Junit 3.8->4
![Page 222: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/222.jpg)
222
Junit & DP
![Page 223: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/223.jpg)
223
Héritage versus compositionStack 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()); }
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); }
Vector
Stack
ArrayList
LoggedList
![Page 224: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/224.jpg)
224
RMI : Securité
Depuis java2, utiliser la sécurité 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;
};
![Page 225: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/225.jpg)
225
RMI :UML
UnicastRemoteObject
Remote
Sujet<<interface>>
+Afficher(): void raises RemoteException
RemoteException<<exception>>
SujetReel
+Afficher(): void raises RemoteException+SujetReel() raises RemoteException+main()
main: SujetReel leSujetReel = new SujetReel(); Naming.rebind("BonjourDeLoin", leSujetReel);
Client
+main()
rmiregistry(Sujet)Naming.lookup
![Page 226: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/226.jpg)
226
//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"); }
}
//Sujet.java
import java.rmi.*;public interface Sujet extends Remote {public void Afficher() throws RemoteException;}
![Page 227: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/227.jpg)
227
// 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");}
}
}
![Page 228: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/228.jpg)
228
RMI :Mise en ouvre
![Page 229: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/229.jpg)
229
Automate-Tableau
![Page 230: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/230.jpg)
230
Refactoring-Métriques
AvantAvant
AprèsAprès
![Page 231: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/231.jpg)
231
Abuser Metriques
Sans DP
Avec DP
![Page 232: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/232.jpg)
232
LocomotiveSurCoussin lr =new LocomotiveSurCoussin();
WagonSurRail wr =new WagonSurRail();
lr.Accrocher(wr);
lr.Rouler();
FabriqueAbstraite f1 ;
Locomotive lrail;
Wagon wrail ;
f1 = new FabriquePourRail();
lrail = f1.CreerLocomotive();
wrail = f1.CreerWagon();
lrail.Accrocher(wrail);
lrail.Rouler();
f1 = new FabriquePourCoussin();
lrail = f1.CreerLocomotive();
wrail = f1.CreerWagon();
lrail.Accrocher(wrail);
lrail.Rouler();
La loco sur coussin d'air vole
La wagon sur rail roule
La loco sur rail roule
La wagon sur rail roule
La loco sur coussin d'air vole
La wagon sur coussin d'air vole
![Page 233: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/233.jpg)
233
Locomotive<<interface>>
~Rouler()~Accrocher(p: Wagon)
Wagon<<interface>>
~Rouler()
LocomotiveSurRail
+Accrocher(w: Wagon)+Rouler()
-monWagon
WagonSurRail
+Rouler()
LocomotiveSurCoussin
+Accrocher(w: Wagon)+Rouler()
-monWagon
WagonSurCoussin
+Rouler()
FabriqueAbstraite<<interface>>
~CreerLocomotive(): Locomotive~CreerWagon(): Wagon
FabriquePourRail
+CreerLocomotive(): Locomotive+CreerWagon(): Wagon
FabriquePourCoussin
+CreerLocomotive(): Locomotive+CreerWagon(): Wagon
![Page 234: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/234.jpg)
234
Le Robot
![Page 235: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/235.jpg)
235
![Page 236: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/236.jpg)
236
Le Robot : Composite
Composite
![Page 237: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/237.jpg)
237
![Page 238: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/238.jpg)
238
![Page 239: Design Patterns Java](https://reader038.vdocuments.site/reader038/viewer/2022102517/54bde3054a79594e6a8b4658/html5/thumbnails/239.jpg)
239
Métriques : InstabilityAfferent Coupling (CA): Le nombre de classes hors d'une package qui dépendent
d'une classe dans le packageEfferent Coupling (CE): Le nombre de classes dans un packages qui dépendent 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 dépendances entre les paquets.
CA = 0
CE = 2
RMI = 1
CA = 2
CE = 0
RMI = 0
CA = 2
CE = 1
RMI = 0,33