Design Patterns Java

• 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

Pourquoi faire de l'objet(1) ?

IncreasedProductivity

Cost savings

Improvedinterfaces

Software reuse

Improvedapplicationmaintenance

Encapsulateexistingapplications

Develop strategicapplicationsquickly

Developapplications asrevenue source

Access new OSand tools

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

Introduction aux Design Patterns

Les Patterns GRASS

General ResponsabilityAssignement Software Patterns

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.

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)

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

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()

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)

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

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

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)

Principes fondamentaux de conception

Ouverture-Fermeture OCPInversion des dépendances DIP

Substitution de Liskov LSP Séparation des interfaces ISP

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

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

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 :

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.

Exemple : (OCP)

Personne

nom : stringage : int

Personne(n : string, a : int)

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

Exemple : (OCP) Solution

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)

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.

I0<<Interface>>

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)

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

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

ObjetMetier

IObjetMetier<<interface>>

ObjetMetier

IObjetMetier

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.

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 :

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 :

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

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".

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 :

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 :

Processus ObjetUP

XP-Agile

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

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

UP & les modèles UML (1)

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)

UP & L'organisation matricielle

Processus Objet

XP-Agile

Extrem programing

La programmation extrême

Les processus agiles

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.

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

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.

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.

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

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?)

•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

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.

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

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

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

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

Ê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

Déroulement

Processus Objet

Refactoring

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..*

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); }

Junit : lancement du test

Regrouper les tests :Sur un projet ou un packageFaire new JunitTestSuite(Other)

Junit4

Tests : Les couches

Blabla

Objetsmétier

Serialisation

• Les objets métier offrent des interfaces pour les IHM (le CTRL)• En analyse : Les trois axes d' une classe

Stringglobal

Couverture de test

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

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)

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

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.

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.

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. .

Refactoring : exercice(1)

Client

-nom: String-lesLocations: Vector = new Vector()

<<create>>+Client(name: String)+addRental(arg: Location)+getNom(): String+statement(): String

+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)

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.

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

+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

Les Design patterns

Le GoF

Comportement

Structure

Création

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

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.

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

Classification des patterns

Création

Comportement

Structure

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

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.

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.

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 ……….

State : UML

Client

+Op1(Context)+Op2(Context)+Op3(Context)

+Op1(Context)+Op2(Context)

+Op2(Context)+Op3(Context)

Context

+Op1()+Op2()+Op3()~SetEtat(Etat)

Client

Context

+Op1()+Op2()+Op3()-SetEtat(Etat)

+Op1(): Etat+Op2(): Etat+Op3(): Etat

+Op1(): Etat+Op2(): Etat

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.

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 ]

State : Exercice1- La banque

Account

owner : string

Account(string : o)GetBalance() : doubleGetState() : *StateSetState(ps : *State) : voidDeposit(c : double) : voidWithDraw(c : doubble) : voidPayInterest() : void

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

GoldenState

balance<0 => Interet 0%

Balance entre 0 et 1000 => Interet 10%

Balance > 1000 => Interet 50%

balance<0 => Pénalité de 15

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;}

Silverr

Silver

State + SingletonE1

C1() {monEtat->C1(this)}

$ instance : *E1

$GetInstance() : *E1C1(p : *Objet)C2(p : *Objet)

<<Singleton>>E2

$ instance : *E2

$GetInstance() : *E2C1(p : *Objet)C2(p : *Objet)C3(p : *Objet)

<<Singleton>>

$ instance : *E3

$GetInstance() : *E3C2(p : *Objet)C3(p : *Objet)

<<Singleton>>

C1(p : *Objet)C2(p : *Objet)C3(p : *Objet)

C1()C2()C3()SetState(p : *Etat)

+monEtat

C1(--) {"Erreur"}

C1() {"OK"}C2() {"OK";p->SetState (E2)}

State + SingletonExo2

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();

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

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.

Stratègie : UML

Context

+ContextInterface()

Strategie

+Algorithme()

ConcreteStrategieA

+Algorithme()

+maStrategie

ConcreteStrategieB

+Algorithme()

Client

Context

+Op1()+Op2()+Op3()-SetEtat(Etat)

+Op1(): Etat+Op2(): Etat+Op3(): Etat

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.

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

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

Patron de méthode : Exemple

TravaillerMatin();Dejeuner();TravaillerApresMidi();Loisir();Dormir();

Patron de méthode

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

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

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();

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

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

ImpotsCelibataire

ImpotsCelibataireLiberal

Payer()

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

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

l’Observer : UML

Observer<<Interface>>

+UpDate()

+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, …)

l ’Observer : la dynamique

: Observer1 : SujetConcret : Observer2

setState()

notify()

UpDate()getState()

UpDate()remove()

setState()

notify()

UpDate()getState()

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.

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)

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

Observer : Exercice1

Observable

-changed: bool

+addObserver(Observer)+deleteObserver(Observer)+countObservers(): int+deleteObservers()+notifyObservers()#setChanged()

Observer

-temperature: int

+setChanged()+calculer()

+getTemperature(): int

Skieur

+update(p1: Observable, p2: Object)

Nageur

+update(p1: Observable, p2: Object)

+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

Observer : Exercice2

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

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>>

Accept(v1): void

Visit(Element e): voida=Operation1()

b=Operation2()

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.

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

Visitor :correction

Main_1

+main(args: String)

IVisitor<<interface>>

~Visit(element: Element)

IncomeVisitor

+Visit(element: Element)

VacationVisitor

+Visit(element: Element)

<<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)

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

RestoreMemento(m){state = m.GetState();}

SaveMemento(){m = new Memento();m.SetState(state);return m;}

SetMemento(p ){moMemento = p;}

GetMemento() : Memento{return monMemento;}

Client

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

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; }}

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

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()

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()

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

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

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();}

+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()

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

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

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

Chain of Resp : UML

Deux temps :• Configurer la hiérarchie• Faire des demandes

Client Handler

+HandleRequest()

ConcreteHandler

+HandleRequest()

-successor

Gere la request si possiblesinon successor.HandleRequest();

: Client Grouillot : ConcreteHandler successor : ConcreteHandler

HandleRequest()

[OK] [NOK] : HandleRequest()

[OK-NOK]

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.

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);

F Directeur

Acheter(p : Achat)

VicePresident

Acheter(p : Achat)

President

Acheter(p : Achat)

Approver

SetSuccesseur(p : *Approver)<<Abstract>> Acheter(p : Achat)

0..1+Chef

Prix : intlibelle : string

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)

Command : UMLClient Invoker

Command

+Execute()

ConcreteCommand

+Execute()

Receiver

+Action() -receiver

receiver.Action()

: Client : ConcreteCommand a : Receiver : Command : Invoker

<<create>>

SetReceiver(a)

Execute

Execute(): voidAction(): void

Configurateur Utilisateur

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)

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

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

+FaireMur()+Recette(): boolean

-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

Interpreter : UML

Context

Client

AbstractExpression

+Interpret()

TerminalExpression NonterminalExpression

Mediator : UMLMediator

ConcreteMediator

Colleague

+mediator

boutonbouton

listeliste

textAreatextArea

ControleurControleur

menumenu

Rmq :Façade-Observer

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.

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

• ……….

Proxy : UML

Proxy.Operation1() {fait qqchose…..leSujet.Operation1();}

Proxy.Proxy(Sujet param){leSujet = param;}

+Operation1()

SujetReel

+Operation1()

+Operation1()+Proxy(p: Sujet)

+leSujet

Client

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.

Proxy DistantRPCRMI

DCOMWEBSERVICE

SujetReel

+Operation1()

+Operation1()+Proxy(p: Sujet)

+Operation1()

Client

Stub skeleton

CallRMIC

IDLInterfaceWSDL

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) {…}

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

Proxy de protection :exercice (1)

+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()

Proxy de protection :exercice (2)

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)

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

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;}

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;}

Proxy invocationHandler :Exercice(1)

Rmq basedonnees est une Hashtable----------------------------------------------Passage difficile :

Proxy invocationHandler :Exercice(2)

Decorator : Présentation

Problème : nombreux héritages

Solution : Héritage héritage + agrégation (poupée russe)

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()

Espresso

Cout()

Boisson

description

Colombia

Cout() Sumatra

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

Decorator :Le problème(2)

Boisson

descriptionlaitvanillechocolat

GetDescription()Cout()SetLait()GetLait()SetVanille()GetVanille()

Colombia

Cout() Sumatra

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

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

Decorateur1

+Operation()+Decorateur1(Component)

Decorateur2

+Operation()+Decorateur2(Component)

ComposantConcret.Operation : fin de la chaîne

Decorateur.Operation() :monComposant.Operation()

Decorator : la solution construction

Component

+Operation()

ComposantConcret

+Operation()

Decorateur

+Operation()

-monComposant

Decorateur1

+Operation()

Decorateur2

+Operation()

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()));

De l'extérieure, on ne voitque le citron.

Decorator : la solution

Component

+Operation()

ComposantConcret

+Operation()

Decorateur

+Operation()

-monComposant

Decorateur1

+Operation()

Decorateur2

+Operation()

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 €

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.

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

Que se passe-t-il si on rajoute la crème Chantilly?Il faut rajouter la classe Chantilly

Colombia

Cout()

Sumatra

Cout()

Espresso

Cout()

Boisson

description

Ingredient

GetDescription()

Cout()Lait(p : Boisson)

Chocolat

Cout()Chocolat(p : Boisson)

Vanille

Cout()Vanille(p : Boisson)

+maBoisson

Citron

Colombia

Decorator : Un mauvais exemple(1)

Display() : voidBook(author : string, title : string, numCopies : int) : Book

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

Borrowable

Display() : voidBorrowable(libraryItem : LibraryItem*) : BorrowableBorrowItem(name : string) : voidReturnItem(name : string) : void

Decorator : un mauvais exemple (2)

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)

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

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()

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.

L'adaptateur : Exercice

Cancaneur

+Cancaner()

Cacardeur

+Cacarder()

Canard

Leurre

CanardPlastique

+Cacarder()

Canard.Cancaner "Coincoin"Leurre.Cancaner "Silence"CanardPlastique "Pchiff"Oie.Cacarder " CoincoinCoincoin "

Pb : Faire cancaner une troupe de Cancaneur contenant des oies

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

+Operation()

+lesEnfants*

Operation()pour chaque enfant :Faire Operation()puis faire qq chose sibesoin pour le composite

Comparer avec le décorateur

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

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

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()

Façade : UML

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.

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

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

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

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

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

• 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

Bridge : UML

Rmq : ressemble au state

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(); }

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.

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

Le singleton uml

ClasseSingleton

<<static>> uniqueInstancedonnéeInstance

<<static>> Instance()OpérationSingleton()

Instance() { retourne uniqueInstance}

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.

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)

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

Fabrication : exemple les pizzerias(1)

FabriqueDePizzasBrest

~creerPizza(item: String): Pizza

FabriqueDePizzasStrasbourg

~creerPizza(item: String): 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

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

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

Fabrication : le Design pattern

Createur

+Fabrication(type: String): Produit+uneOperation()

CreateurConcret

+Fabrication(type: String): Produit

ProduitConcret1

+fqq()

ProduitConcret2

+fqq()

Produit

+fqq()

Client

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.

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();

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

Fabrication Abstraite : Structure

FabriqueAbstraite

CreerProduitA()CreerProduitB()

FabriqueConcrete1

FabriqueConcrete2

ProduitAbstraitA

ProduitAbstraitB

ProduitA1 ProduitA2

ProduitB1 ProduitB2

Application

<<instancie>>

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

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

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.

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

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

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()

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

#vehicule

MotoBuilder

BuildMoteur() : voidBuildRoue() : voidBuildPorte() : voidMotoBuilder()

VoitureBuilder

BuildMoteur() : voidBuildRoue() : voidBuildPorte() : voidVoiturBuilder()

Construire(p : VehiculeBuilder) : void

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#)

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.

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

Observer

Strategie

Template methode

memento

Singleton

Observer

Strategie

Template methode

memento

DP : Exercice général(1)

Tester()InitNote()$GetInstance()

-$instance

LeMeilleur

Tester()InitNote()$GetInstance()

-$instance

Strategie

note : int

Rechercher()Tester()InitNote()

Exercice(p : Stagiaire*) : intGetEtat() : stringEtat(n : string) : Etat

EtatTM

Exercice()EtatTM()$GetInstance()

Exercice()EtatB()$GetInstance()

Entreprise

Update() : voidEntreprise(n : string) : EntrepriseDebaucher() : void

Observer

Update()

Personne

Update() : voidVirer() : voidPersonne(n : string) : Personne

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

-state

LaClasse

Exercice() : voidAjouterStagiaire(p : Stagiaire*) : voidAfficher() : void$GetInstance() : LaClasse*Rechercher(s : Strategie*) : string

-$instance0..1

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

+cacarder()

Adaptateur

Decorateur

Fabrique abstraite

Composite

Observer

Adaptateur

Decorateur

Fabrique abstraite

Composite

Observer

Autres Patterns

Les classes d'analyse

Le raii

Les classes d'analyse• Les trois axes d'une classe :

• Boundery - Frontière - Vue• Contrôleur• Entity - Objets métier - modèle

protocole

uc1<<useCaseRealization>>

vue1 c1

e1 e2m1m2

vue1 c1

RAII : Présentation du pb

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

(RAII) à la sauce Java (Finally)

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 :

Patterns et architecture

FrameWork

Organisation des packages

Métriques

Patterns et architecture

FrameWork

Métriques

Controleur

Modele

(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

Controleur

ModeleComposite

Stratégie/etat

SujetObserver UpDate()

laVue Strategie

+PushButton()

+ClickMenu()

MVC : Design pattern composé

VueDos VueSwing

-composite

+Update()

ObjetMetier

Configuration

-fabrique-abstraite

Utilisable

Gerable

Controleur

-state-strategie

+Attach(o: Vue)+Detach(o: Vue)+Notify()

UtilisableGerable

Utilisateur

Utiliser

Systeme

-Configurer+Utiliser

Util Conf

ConfigurerUtiliser

Util Conf

ConfigurerUtiliser

LeCtrl

utilisable gerable

Lecture

UneVue

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 ….

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

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.

Op1()Fqq()

(f rom PA)

Op2()Fqq()

(f rom PB)+monB+monAOp1{b.Fqq()}

Op2{a.Fqq()}

monA : A : Application : A monB : B

Op1( )

Fqq( )

Op2( )

Fqq( )

Dépendances cycliques : Interface

FqqAble

(f rom Interf ace)

<<Interface>>

Op1()Fqq()AddmonB(p : FqqAble)

(from PA)

Application

Op2()Fqq()AddMonA(p : FqqAble)

(from PB)

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

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

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.

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

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

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

Junit 3.8->4

Junit & DP

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

ArrayList

LoggedList

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;

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

//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[])

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;}

// 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());

Sujet monSujet = (Sujet)Naming.lookup("rmi://127.0.0.1/BonjourDeLoin");

monSujet.Afficher();

}catch (Exception e) {System.out.println ("excpt");}

RMI :Mise en ouvre

Automate-Tableau

Refactoring-Métriques

AvantAvant

AprèsAprès

Abuser Metriques

Sans DP

Avec DP

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

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

Le Robot

Le Robot : Composite

Composite

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

Design Patterns Java

Technology

J2ee (java ee) design patterns and architecture

GoF Design Patterns · 2018-11-26 · 2. Logica Java Architects Training Crew Design Patterns- Explained Chapter 1 Creational Patterns “Creational design patterns are design patterns

Design Patterns in Java Chapter 23 Strategy

Design Patterns in Java Chapter 8 Singleton

Design Patterns Em Java

Java Design Patterns With Examples

Java Design Patterns - IT College › ~jpoial › java › naited › Java... · Java Design Patterns viii Preface A design pattern is a general reusable solution to a commonly occurring

1 SD Java Design Patterns. 2 SD Java Design Patterns Layered Initialization Dynamic Linkage Cache Management Null Object All these patterns are from:

Java Design Patterns - IT Collegeenos.itcollege.ee/~jpoial/java/naited/Java-Design-Patterns.pdf · Java Design Patterns iv 10 Chain of Responsibility Design Pattern66 10.1 Chain of

Design Patterns in Java Technology

Design Patterns in Java Chapter 3 Adapter

k19 k51 Design Patterns Em Java

Modern Java EE Design Patterns - pepa.holla.czpepa.holla.cz/.../uploads/2016/10/modern-java-ee-design-patterns.pdf · Markus Eisele Modern Java EE Design Patterns Building Scalable

Java day2016 "Reinventing design patterns with java 8"

Modern Java EE Design Patterns Red Hat

Design Patterns in Java Chapter 4 Façade

Enterprise Java Design Patterns Mock Exam

JAVA design patterns and Basic OOp concepts

Refactoring and Retroﬁtting Design Patterns in Java Software …dig.cs.illinois.edu/papers/refactoringSPL_ASE16.pdf · Refactoring and Retroﬁtting Design Patterns in Java Software

Software architecture design patterns in java 2004