design patterns java
DESCRIPTION
Design patternsObserver, Decorateur, State, template methodeTRANSCRIPT
1
Design Patterns JAVA
Conception d’applications objet
B.Vinot
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
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
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
5
Introduction aux Design Patterns
Les Patterns GRASS
General ResponsabilityAssignement Software Patterns
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.
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)
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
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()
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)
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
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
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)
14
Principes fondamentaux de conception
Ouverture-Fermeture OCPInversion des dépendances DIP
Substitution de Liskov LSP Séparation des interfaces ISP
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
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
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 :
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.
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
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)
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
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
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
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.
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 :
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 :
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
28
Principes de séparation des interfaces (ISP)
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".
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 :
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 :
32
Processus ObjetUP
XP-Agile
Winston Royce. Managing the Development of Large Software Systems. 1970
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
34
UP & les modèles UML (1)
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)
36
UP & L'organisation matricielle
37
Processus Objet
XP-Agile
Extrem programing
La programmation extrême
Les processus agiles
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.
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
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.
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.
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
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?)
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
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.
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
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
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
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
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
51
Déroulement
Scrum
52
Processus Objet
Tests
Refactoring
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..*
54
Junit
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); }
}
56
Junit : lancement du test
Regrouper les tests :Sur un projet ou un packageFaire new JunitTestSuite(Other)
Junit4
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
58
Couverture de test
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
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)
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
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.
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.
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. .
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.
66
Refactoring : exercice(2)
67
Refactoring : exercice(3)
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
69
Les Design patterns
Le GoF
Comportement
Structure
Création
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
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.
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
73
Classification des patterns
Création
Comportement
Structure
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
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.
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.
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 ……….
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
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.
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 ]
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
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
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)}
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();
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
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.
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
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.
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
*
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
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
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
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();
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
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()
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
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
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, …)
99
l ’Observer : la dynamique
: Observer1 : SujetConcret : Observer2
add()
add()
setState()
notify()
UpDate()getState()
UpDate()remove()
setState()
notify()
UpDate()getState()
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.
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)
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
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
?
104
Observer : Exercice2
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
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()
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.
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
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)
*
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
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
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; }}
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
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()
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()
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
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
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()
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
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
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
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]
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.
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
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)
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
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)
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
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
130
Interpreter : UML
Context
Client
AbstractExpression
+Interpret()
TerminalExpression NonterminalExpression
*
131
Mediator : UMLMediator
ConcreteMediator
Colleague
+mediator
boutonbouton
listeliste
textAreatextArea
ControleurControleur
menumenu
Rmq :Façade-Observer
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.
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
• ……….
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
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.
136
Proxy DistantRPCRMI
CORBA
DCOMWEBSERVICE
SujetReel
+Operation1()
Proxy
+Operation1()+Proxy(p: Sujet)
Sujet
+Operation1()
Client
Call
Stub skeleton
Send
CallRMIC
IDLInterfaceWSDL
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) {…}
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
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()
140
Proxy de protection :exercice (2)
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)
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
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;}
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;}
145
Proxy invocationHandler :Exercice(1)
Rmq basedonnees est une Hashtable----------------------------------------------Passage difficile :
146
Proxy invocationHandler :Exercice(2)
147
Decorator : Présentation
Problème : nombreux héritages
Solution : Héritage héritage + agrégation (poupée russe)
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
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
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()
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.
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 €
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.
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
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
156
Decorator : un mauvais exemple (2)
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)
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
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()
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.
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
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
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
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
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()
**
166
Façade : UML
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.
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
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
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
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
*
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
173
Bridge : UML
Rmq : ressemble au state
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(); }
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.
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
177
Le singleton uml
ClasseSingleton
<<static>> uniqueInstancedonnéeInstance
<<static>> Instance()OpérationSingleton()
Instance() { retourne uniqueInstance}
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.
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)
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
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
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]
183
Fabrication : le Design pattern
Createur
+Fabrication(type: String): Produit+uneOperation()
CreateurConcret
+Fabrication(type: String): Produit
ProduitConcret1
+fqq()
ProduitConcret2
+fqq()
Produit
+fqq()
Client
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.
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();
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
187
Fabrication Abstraite : Structure
FabriqueAbstraite
CreerProduitA()CreerProduitB()
FabriqueConcrete1
CreerProduitA()CreerProduitB()
FabriqueConcrete2
CreerProduitA()CreerProduitB()
ProduitAbstraitA
ProduitAbstraitB
ProduitA1 ProduitA2
ProduitB1 ProduitB2
Application
<<instancie>>
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
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()
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.
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
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
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()
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
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#)
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.
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
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
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
200
Autres Patterns
Les classes d'analyse
Le raii
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
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
203
(RAII) à la sauce Java (Finally)
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 :
205
Patterns et architecture
MVC
FrameWork
Organisation des packages
Métriques
206
Patterns et architecture
MVC
FrameWork
Organisation des packages
Métriques
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
208
Vue
Controleur
ModeleComposite
Stratégie/etat
SujetObserver UpDate()
laVue Strategie
ctrl1
+PushButton()
Ctrl2
+ClickMenu()
MVC : Design pattern composé
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
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 ….
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
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.
213
Organisation des packages
K
L
A B
I
E
J
G
D
H
C
F
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( )
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
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
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.
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
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
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
221
Junit 3.8->4
222
Junit & DP
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
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;
};
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
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;}
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");}
}
}
228
RMI :Mise en ouvre
229
Automate-Tableau
230
Refactoring-Métriques
AvantAvant
AprèsAprès
231
Abuser Metriques
Sans DP
Avec DP
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
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
234
Le Robot
235
236
Le Robot : Composite
Composite
237
238
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