Vous êtes sur la page 1sur 52

3012 Mise en oeuvre des Design Patterns sur une tude de cas

Pascal Roques Consultant senior et formateur

Introduction

Prsentations Programme

Prsentations
Intervenant : Pascal Roques

Consultant senior chez Responsable des formations autour de lanalyse et de la conception objet avec UML Auteur de 3 ouvrages sur UML parus chez Eyrolles :
UML par la pratique
Cours et exercices Java et C# - 2me dition

UML en action - 2e dition


De l'analyse des besoins la conception en Java

UML - Modliser un site e-commerce


Les Cahiers du Programmeur

Notre programme
1. Introduction 2. Les Design Patterns 3. Analyse de ltude de cas (Together) 4. Application des Design Patterns (Together) 5. Conclusion

Les Design Patterns

Introduction aux DP GoF : State, Singleton, Template Method De lanalyse la conception Application ltude de cas

Introduction aux patterns


Le succs dune conception passe par lattribution

russie des bonnes responsabilits aux bonnes classes

Problme : les dcisions qui vont conduire des

systmes extensibles et maintenables ne sont pas forcment videntes

Solution : il y a des principes fondamentaux et

prouvs appels patterns que tout concepteur expriment applique

Introduction aux patterns


Les patterns sont : Des paires nommes (problme + solution) Des conseils issus de la pratique dexperts

Une technique essentielle dans le monde de la conception oriente objet !

Les concepteurs aguerris conoivent par le

biais dun langage de patterns

Dans cette conception, jai associ les patterns State (tat) et Singleton pour faciliter lajout de nouveaux tats Vaudrait-il mieux que jutilise le Flyweight ?

Ressources sur les patterns


Exemples de patterns et de ressources : Patterns GRASP

Neuf patterns dattribution des responsabilits fondamentales UML et les Design Patterns (Larman, 2001, CampusPress). 23 patterns courants dans des situations spcifiques Le plus connu des ensembles de patterns orients objets Design Patterns (Gamma, et. al. 1995, AW). 50 patterns courants avec leur traduction en Java Patterns in Java (Grand, 2003, Wiley).

Les patterns Gang of Four (GoF)


Les patterns en Java


Modle de description (1/3)


Nom du pattern

Le nom du pattern vhicule succinctement lessence du pattern Il est essentiel de trouver un nom clair et facile mmoriser ! Formule brve rpondant aux questions suivantes :

Intention

Que fait le design pattern ? Quels en sont le raisonnement et lintention ? Quel problme spcifique de conception traite-t-il ?

galement appel

Autres noms connus du pattern, sil en existe (alias) Scnario illustrant un problme de conception ainsi que la faon dont les structures de classes et dobjets du pattern rsolvent le problme

Motivation

source : Design Patterns Elements of Reusable Object-Oriented Software

Modle de description (2/3)


Applicabilit Quelles sont les situations dans lesquelles le design pattern peut tre appliqu ? Quels sont les exemples de mauvaises conceptions que le pattern permet de traiter ? Structure Gnralement, reprsentation graphique des classes du pattern cre laide dUML Participants Classes et/ou objets prenant part au design pattern avec leurs responsabilits respectives Collaborations Faon dont les participants collaborent afin dassumer leurs responsabilits Patterns connexes Quels sont les design patterns lis de prs celui-ci ? Avec quels autres patterns celui-ci doit-il tre utilis ?
source : Design Patterns Elements of Reusable Object-Oriented Software

Modle de description (3/3)


Consquences

De quelle faon le pattern accomplit-il ses objectifs ? Quels sont les compromis et les rsultats lis lutilisation du pattern ? Quels sont les piges, les conseils ou les techniques dont il faut avoir connaissance lors de la mise en uvre du pattern ? Y a-t-il des questions spcifiques au langage ? Fragments de code illustrant la faon dont on pourrait mettre en uvre le pattern avec un langage orient objets Exemples dutilisation du pattern sur des systmes rels

Implmentation

Exemple de code

Usages connus

source : Design Patterns Elements of Reusable Object-Oriented Software

Les Design Patterns GoF

source : Design Patterns Elements of Reusable Object-Oriented Software

Le DP Singleton (1/2)
Problme : comment garantir la prsence dune seule

instance dune classe et fournir un point daccs global cette instance ?

Solution : sauvegarder lobjet singleton dans une

variable statique et implmenter une mthode de classe retournant ce singleton


Notez que cela fournit un accs global sans les dfauts des variables globales Le constructeur est dclar priv (ou mieux : protg)

Le DP Singleton (2/2)

Le DP Template Method (1/2)


Le pattern Template Method (TMP) est au cur de la

conception dalgorithmes gnriques variables et non variables ?

Problme : comment concevoir des algorithmes Solution : dfinissez le squelette dun algorithme dans

une mthode de super-classe, en confiant certaines tapes des sous-classes

Le DP Template Method (2/2)

Le DP State (1/2)
Problme : le comportement dun objet dpend de son

tat

lobjet doit changer de comportement lexcution Il est ncessaire que la rponse dune instance varie en fonction de son tat
public public void void m1(){ m1(){ if if < < test test 1 1> > methodA() methodA() else else if if < < test test 2 2> > methodB() methodB() } } public public void void m2(){ m2(){ if if < < test test 1 1> > methodC() methodC() else else if if < < test test 2 2> > methodD() methodD() } } public public void void m3(){ m3(){ if if < < test test 1 1> > methodE() methodE() else else if if < < test test 2 2> > methodF() methodF() } }

Solution : dlgation + polymorphisme

Classe abstraite (ou interface) Etat

Le DP State (2/2)

Analyse de ltude de cas

Prsentation Analyse des besoins Modle du domaine

Ltude de cas (1/2)


Le jeu du Dmineur

Ltude de cas (2/2)


Lobjectif de cette tude de cas est de concevoir un jeu de

dmineur comme celui qui est livr avec Windows

Nous souhaitons utiliser un processus itratif et incrmental

La dmarche classique de modlisation que nous allons

appliquer est la suivante :

Analyse des besoins


Diagramme de cas dutilisation Diagramme de squence systme Diagramme de classes Diagramme dtats Diagramme de classes Diagrammes dinteractions

Modle du domaine

Modle de conception objet


Analyse des besoins (1/2)


Diagramme de cas dutilisation
Paramtrer le jeu <<extend>> [Paramtrage]

Joueur

Jouer au dmineur Extension points Paramtrage Help <<extend>> [Help] Consulter l'aide en ligne
Itration 1 : avec paramtrage par dfaut, et non prise en compte du marquage ?

Analyse des besoins (2/2)


Diagramme de squence systme
Demineur Joueur initialiser()

decouvrirCase(Point) marquerCase(Point)

etc.

decouvrirCase(Point) gagn !! entrerNomHighScores(n)

Modle du domaine (1/2)


Diagramme de classes du domaine

Modle du domaine (2/2)


Diagramme dtats : la classe Case

Complexit itrative !

Itration 1 Itration ultrieure

Application des Design Patterns


avec Together

Conception DP State DP Singleton DP Template Method

Architecture logique
Le modle du domaine va nous servir de base pour la

couche domaine de notre architecture logique en conception objet

Modle simplifi en 3 couches

De lanalyse la conception (1/3)


Dans le diagramme de classes, nous allons

maintenant indiquer :

Les mthodes La navigabilit des associations Les dpendances entre classes Les types des attributs et des mthodes (retour, paramtres)

Together permet dajouter facilement les

constructeurs, accesseurs, etc.

De lanalyse la conception (2/3)


Le modle du domaine fournit des classes candidates

pour le diagramme de classes de conception

Le concepteur peut tre amen fusionner certains concepts ou au contraire introduire de nouvelles classes de conception

tat ??

De lanalyse la conception (3/3)


Diagramme de classes de conception

premier jet pour litration 1

Classes de conception
Ajout des types non-primitifs (optionnel)

Conception de la dynamique (1/3)


Pour chaque opration systme complexe, nous

allons raliser un diagramme dinteraction (collaboration ou squence)


Dmineur Joueur initialiser() decouvrirCase(Point) marquerCase(Point)

La complexit se

trouve dans les deux oprations :


etc.

decouvrirCase(Point) marquerCase(Point)

decouvrirCase(Point) gagn !! entrerNomHighScores(n)

Conception de la dynamique (2/3)


Commenons par marquerCase :

Le joueur clique sur un point du plateau, il faut dj traiter lvnement graphique en trouvant la case concerne
1: marquerCase(Point) :Partie

1.1: marquerCase(Point)

:Plateau

1.1.1: c:=get(Point)

les:Case

1.1.2: marquer()

1.1.2.1: ?? c:Case

Conception de la dynamique (3/3)


Continuons marquerCase :

Si elle est toujours couverte, une case peut tre marque en respectant les rgles indiques par le diagramme dtats Le traitement effectuer dpend donc entirement de ltat de la case pointe

Nous allons utiliser le Design pattern du State

du marquage ? )

!Avantage : volutivit facilite (pour la prise en compte ultrieure

Application du DP State (1/4)


Diagramme de classes de conception avant

Ajout des mthodes dans Plateau et Case

Application du DP State (2/4)

Application du DP State (3/4)


Diagramme de classes de conception aprs !

Application du DP State (4/4)


Le code Java correspondant aprs !

Suite de la dynamique (1/2)


Continuons marquerCase :

En fonction de son tat, la case effectue des traitements diffrents


marquer(c : Case) :EtatDecouverte

marquer(c : Case)

:EtatCouverteNonMarquee

2: majCompteur(-1)

<<singleton>>

:Partie

1: setEtatCourant(EtatDrapeau)

c : Case

marquer(c: Case) :EtatDrapeau 2: majCompteur(1)


<<singleton>>

:Partie

1: setEtatCourant(EtatCouverteNonMarquee)

c : Case

Suite de la dynamique (1/2)


Quelles sont les amliorations du modle que ltude

de la dynamique nous inspire ?


marquer() marquer(c : Case) Idem pour decouvrir(c : Case)

Les tats doivent recevoir en paramtre la case elle-mme pour

pouvoir ensuite invoquer la mthode setEtatCourant()


De nombreuses classes vont avoir besoin dun accs la

classe Partie : tous les tats, etc. Cette classe Partie doit avoir une seule instance la fois !

Lutilisation du DP Singleton est naturelle

Suite de la dynamique (2/2)


Appliquons le DP Singleton la classe Partie

Application du DP Singleton
Le modle et le code Java correspondant aprs !

Classes de conception
Le modle

complt de litration 1 pourrait alors ressembler :

Dveloppement itratif
Le DP State facilite lintroduction itrative dun nouvel

tat de marquage de la case

Itration 1

Itration ultrieure

Nouvelle application du State (1/2)


Together permet facilement dajouter un nouvel tat

concret

Grce au paramtre create pattern links qui reconnat les participants au DP

Nouvelle application du State (2/2)


Diagramme de classes de conception aprs !

Conclusion

Pas de pattern-alisme excessif !


Une bonne conception nimplique pas dutiliser tous

les patterns de la terre !

Utilisez les bons patterns au bon endroit et justifiez votre solution ! Il est rare de raliser une bonne conception ds la premire tentative

Lactivit de refactoring aide rectifier les erreurs Dveloppez de faon itrative

vitez le syndrome du silver bullet !


Utilisation obsessionnelle dun pattern ou dune technologie auxquels vous tes habitu Mfiez-vous de ceux qui disent avoir un pattern prfr !

Utilisez Together !

Together permet dappliquer plus facilement des patterns sur vos modles UML Il permet galement de se crer ses propres patterns ! Mais ceci est une autre histoire

Questions?

Merci !

Noubliez pas de remplir le formulaire dvaluation Vous pouvez me contacter pascal.roques@valtech.fr