Chapitre 3 Patrons de Conception GoF

Modélisation et Architecture des Logiciels
Patrons de conception GoF
GUENDOUZI W.
WWW.GUEND.JIMDO.COM
1
Plan
PATRON
• Définition
• Historique
• Avantage et inconvinients
PATRON GoF
• Description
• Classification
• Principes
• Patrons de création
• Patron de structure
• Patron de comportement
2
Patrons – définition –
Patron = recette de conception

Modèle de conception général proposé par des développeurs de
logiciels expérimentés. Une solution à un problème de conception
commun et récurrent.
Intérêt :
• Des solutions issues d’experts
• Un vocabulaire commun pour les développeurs des logiciels
3
Patrons – historique –
Origine : le livre de Christopher Alexander « A Pattern Language :

Towns, Buildings Construction ».
Fondateurs : la publication de Erich Gamma, Richard Helm, Ralph

Johnson et John Vlissides « Design Patterns : Elements of reusable
objected-oriented softwares » en 1995.
=> Ils forment le surnommé GoF (Gang of Four).
4
Patrons – avantages et inconvénients –
Avantages :
• réduire le temps de développement d’une application.
• faciliter la maintenance d’une application.
• faciliter la communication entre les différents développeurs
Inconvénients :
• difficulté à choisir le patron à utiliser
• nécessite de l’apprentissage et de l’expérience.
• les patrons sont nombreux
• les patrons peuvent dépendre d’autres patrons.
5
Patrons – différents patrons –
• Patrons de conception de GoF
• Patrons d’architecture (styles d’architecture)
• Patron d’architecture entreprise
• Patron d’utilisabilité
• …etc.
6
Patrons GoF
7
Description d’un patron de conception
Les patrons de conception sont représentés par :
• Nom : identifier le patrons
• Problématique : description du problème auquel il répond
• Solution : description de la solution souvent accompagnée d’un
schéma UML
• Conséquences : les avantages et les inconvénients de cette
solution (Conséquences de l’application du pattern)
• Autres
Exemples d’implémentation
Conseil d’implémentation
8
Classification des patrons GoF
Les patrons de conception sont classés en trois catégories (GoF).
• Patrons de Création (5) :
- Comment organiser et déléguer la création dynamique d’instances ?
Patterns FactoryMethod, AbstractFactory, Builder, Singleton
• Patrons de Structure (7) :
- Comment composer les classes et les objets pour obtenir des
structures plus complexes ?
- Travaillent essentiellement sur des aspects statiques, à « l’extérieur »
des classes
Bridge, Adapter et Composite (etc.)
9
• Patrons de Comportement (11) :
- Comment faire collaborer classes ou objets pour construire une
partie de l’application et des traitements ?
- Travaillent essentiellement sur des aspects dynamiques, à « l’intérieur »
des classes et parfois au niveaux des instances
Strategy, Decorator, Observer, Visitor (etc.)
10
11
Principes des patrons
• Implémentés différemment en fonction du langage de programmation
utilisé,
• Peuvent être modifiés ou adaptés selon les besoins du système,
• Formulés en termes de classes et d’objets (Exprimés sous forme
d’architecture reliant quelques classes très abstraites)
• Visent à améliorer la qualité du code :
- Souvent orientés vers le bon découpage en package (modularité, flexibilité,
réutilisabilité).
- Favorisent la composition sur l’héritage
- Reposent beaucoup sur les abstractions (interfaces, classes abstraites, Etc.) et
évitent les liens directs avec les classes concrètes
12
Patrons de création
-Singleton-
13
Patrons de création – singleton --
Problème : comment assurer une seule instanciation d’une classe et fournir
un point d’accès global à cette unique instance.
Solution :
• Créer un seul et unique constructeur avec un accès « private ».
• Créer un attribut statique, sa valeur est une instance privée de la classe :
sa valeur est instanciée une première fois, soit directement lors de sa
définition, soit dans la méthode getInstance()
• Créer une méthode publique d’accès à cette instance.
14
Implémentation :
15
Implémentation :
16
Implémentation : exemple 1
17
18
Conséquences :
• Gestion centralisée d’une ressource

• Classes nécessitant une seule instance
19
Patrons de création
-Factory method-
20
Patrons de création – Factory method--
Problème : comment permettre à une classe de définir elle-même ses
propres objets à créer ?
Solution :
• Déléguer l’instanciation à des sous classes en utilisant une méthode
nommée la méthode « Factory » :
cette méthode permet de choisir une classes selon des critères de choix
puis l’instancier et retourner la référence de l’objet crée.
21
• « Product » : définit l’interface des objets que la méthode Factory peut créer
• « ConcreteProduct » : implémente l’interface « product »
• « Creator » : déclare la méthode « Factory » et peut contenir des méthodes
(« operation ») qui font appel à la méthode « Factory »
• « ConcreteCreator » : implémente la méthode abstraite « Factory » qui retourne un
objet « Product » créé avec l’opérateur New.
22
implémentation : exemple 1
23
implémentation : exemple &
Méthode Main :
24
Conséquences :
• Le client n’a pas besoin de savoir toutes les classes à instancier. Il a besoin
de l’interface ou la classe abstraite de l’objet à créer et la méthode
« Factory ».
• La méthode « Factory » encapsule la création d’objets ce qui peut être
utile quand le processus de création est complexe.
25
Patrons de structure
-Composite-
26
Patrons de structure – composite --
Problème : comment représenter une hiérarchie d’objets composants/
composés et les traiter uniformément (pas de distinction entre les
composants simples et leurs compositions)
Solution :
27
28
29
30
31
32
Conséquence
• hiérarchies de classes dans lesquelles l’ajout de nouveaux composants est

simple
• simplification du client qui n’a pas à se préoccuper de l’objet accédé
33
Patrons de structure
-Proxy-
34
Patrons de structure – proxy --
Problème : comment contrôler l’accès à certains types d’objets (objets
distants, couteux en création ou nécessitant d’ètre sécurisés).
Solution :
Créer un objet représentatif qui contrôle l'accès à ces types d’objets : L’objet
proxy. Le client fait appel à l’objet représentatif « proxy » sans qu’il le sache
(le proxy joue le rôle de l’objet source, il fait passer les appels du client à
l’objet source).
Il existe trois variations du proxy:
• proxy distant : fournit un représentant local pour un objet distant.
• proxy virtuel : crée un objet coûteux à la demande.
• proxy de protection : contrôle l'accès à un objet. Il est utile lorsque l’objet
a différents droits d'accès.
35
36
Exemple : proxy virtuel
37
38
39
40
Conséquence :
Cacher le faite que l’objet n’est pas créé (proxy virtuel) par l’ajout d’un
niveau supplémentaire d’indirection lors de l’accès à l’objet.
41
Patrons de comportement
-Observer-
42
Patrons de comportement – Observer --
Problème : comment assurer la cohérence entre des objets communiquant
entre eux tout en maintenant leur indépendance.
Solution :
Patron observer : définir une relation un à plusieurs entre les objets de telle
manière lorsqu’un objet se met à jours tous les objets dépendants soient
notifiés et mis à jour automatiquement.
43
44
Subject : l’interface représentant l’objet observé par un ou plusieurs
observateurs. Elle est utilisée pour l’enregistrement d’un objet en tant que
observer du subject
Observer : interface pour les objets devant être notifiés lors de MAJ du
subject. Elle contient la méthode update appelée lors du changement du
subject.
ConcreteSubject : implémente l’interface du subject. Elle contient la méthode
notifyObserver() utilisé lors de changements d’état pour MAJ les observers.
contient une référence vers les observers.
ConcreteObserver : implémente l’interface observer.
45
46
47
Résumé :
Dans le subject :
• Liste des observers
• Méthode d’ajout et de suppression d’un observer de la liste des observers
• Méthode NotifyObservers() qui parcourt la liste des observers et appelle
la méthode update
• Méthode qui fait des traitements spécifiques au subject et qui à la fin
appelle la méthode NotifyObservers() qui elle appel la méthode Update()
des observers
48
Résumé :
Dans l’observer :
• Référence vers le subject concerné (ou vers un attribut représentant son
état)
• Méthodes d’ajout et de suppression permettant à l’observer de s’ajouter
ou de se retirer de la liste des observers
• Méthode Update()
49
subject
observer
50
Implémentation : exemple 3 (observer dans le package java.util)
• Défini par « extends

observable ».
• Ne contient pas de référence
vers les Observers
• Appelle des méthodes de la
classe mère setChanged() et
subject notifyObservers(string x) dans
la méthode qui effectue le
changement d’état (la
méthode run dans cet
exemple )
51
Implémentation : exemple 3 (Observer dans le package java.util)
• Défini par «implements

observer
Observer».
• Ne contient pas un attribut de
référence vers le subject
• Définition de la méthode
update qui prend en
paramètre le subject et un
Objet.
52
Implémentation : exemple 3 (Observer dans le package java.util)
• Création du subject et de
l’observer.
• Ajouter l’observer à la liste des
observers par la méthode
addObserver(Observer o)
• Il existe aussi la méthode
deletObserver(Observer o).
53
Conséquence :
• Faible couplage entre le subject et l’observers
• Dans des scénarios complexes , il est difficile de déterminer si tous les
observers nécessitent un update ou uniquement certains d’entre eux.
54
Patrons de comportement
-Strategy-
55
Patrons de comportement – Strategy --
Problème : étant donné un ensemble de programmes de la même famille appelés
Stratégies et un programme appelé contexte qui les utilise de la même manière.
Comment permettre à ces différents programmes d’évoluer indépendamment de
ce programme (le contexte).
Solution :
Patron strategy :
• Encapsuler chaque stratégie dans une classe concrète puis concevoir une
interface (ou une classe abstraite) qui sera implémentée par les différentes
stratégies.
• Le contexte est représenté par une classe qui utilise l’interface des différentes
stratégies. Tous changement dans les stratégies est indépendant du contexte.
• Le client doit seulement choisir et instancier la classe stratégie qu’il veut
utiliser.
56
57
Implémentation : exemple
Interface de la stratégie =>
Stratégie 1 =>
Stratégie 2 =>
58
Le contexte =>
59
Le client =>
60
Conséquence :
• Cacher les détails d’implémentation des différentes stratégies.
• Faciliter l’ajout et la suppression des stratégies.
• Simplifier le choix des stratégies.
• le client doit comprendre le principe des stratégies avant d’en choisir une.
61
Sources du cours
[1] Java design pattern. Rohit Joshi. Book, 2015.
[2] GoF Design Patterns with examples using Java and UML.
Benneth Christiansson et al., 2008.
[3] Software engineering. Ian Sommerville. Book, 9th edition,2011.
[4] Design Patterns : Outils pour la Gestion de Projets. Gauthier
Picard, 2007.
[5] Patrons de conception. Bruno Dufour, 2009.
[6] Design Pattern, Ilhem Boussaïd. USTHB, 2009.
[7] Patrons de Conception. Simon Urli, 2015.
62

Chapitre 3 Patrons de Conception GoF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chapitre 3 Patrons de Conception GoF

Transféré par

Droits d'auteur :

Formats disponibles

Modélisation et Architecture des Logiciels

Patrons de conception GoF

Patron = recette de conception

Origine : le livre de Christopher Alexander « A Pattern Language :

Fondateurs : la publication de Erich Gamma, Richard Helm, Ralph

• Gestion centralisée d’une ressource

• hiérarchies de classes dans lesquelles l’ajout de nouveaux composants est

• Défini par « extends

• Défini par «implements

Interface de la stratégie =>

Vous aimerez peut-être aussi