Les applications J2EE et les Frameworks01/05/2004
2. Les design-patterns
2.1. Introduction
2.2. Les modèles de création
2.2.1. Fabrique de création
2.2.2. Singleton
2.2.2. Builder
2.3. Les modèles de structure
2.3.1. Adapter
2.3.2. Proxy
2.3.3. Composite
2.4. Les modèles de comportement
2.4.1. Iterator
2.4.2. Template
2.4.3. Observer
2.5. Le modèle MVC
2.6. Les design-pattern J2EE
2.6.1. Liens entre les différents design-pattern
2.6.2. Pattern du Tiers Présentation
2.6.3. Pattern du Tiers Business
2.6.4. Pattern du Tiers Integration
L'approche orientée objet tend à éclater les applications en composants plus simples et
réutilisables. Cependant, cette approche peut vite devenir un piège lorsque le découpage
s'effectue sans règles précises. Pour réduire les risques de maintenance, il a fallu exploiter
un niveau supplémentaire dans la conception objet : Les modèles de conception ou Design
Patterns.
un Design Pattern décrit un problème récurrent dans un environnement donné, puis il décrit
une solution optimisée à ce problème de telle manière que cette solution soit réutilisable à
chaque fois qu'on rencontre le problème. Les Design Patterns fournissent ainsi des moyens
de transmettre le savoir-faire et l'expérience dans le domaine de la conception orientée objet,
permettant ainsi de l'industrialiser autant que possible.
Les designs patterns ne sont pas réellement normalisés, mais on peut les découper en trois
grandes catégories :
- Les modèles de création – (Gestion des instances) : Ces modèles sont très
courants pour désigner une classe chargée de construire des objets. Ils permettent
de résoudre les contraintes de création :
- instance unique
- mécanisme de cache
- contrôle des valeurs des instances crées
- Les modèles de structure – (Association de classes) : Ces modèles tendent à
concevoir des agglomérations de classes avec des macro-composants, ils permettent de structurer
des problèmes courants.
- Modélisation d’arbres, de graphes
- « poupées russes »
- Les modèles de comportement – (Gestion des interactions) : Ces modèles tentent
de répartir les responsabilités entre chaque classe, et permettent d’obtenir un
comportement spécifique.
- Personnalisation d’algorithmes
- Changement de comportement en cours du cycle de vie
- Réactions aux évênements
2.2. Les modèles de création
On se trouve en programmation objet souvent confronté au problème d'évolution des
classes. Une classe hérite d'une autre classe pour en spécialiser certains éléments. On
aimerait donc qu'un objet puisse appartenir à telle ou telle classe (dans une même famille
par héritage) sans avoir à chercher la classe de gestion de ces objets et la ligne de code qui
effectue l'instanciation.
2.2.1. Fabrique de création
Une fabrique de création (ou factory) est une classe qui n'a pour rôle que de construire des
objets. Cette classe utilise des interfaces ou des classes abstraites pour masquer l'origine
des objets.
Un singleton sert à contrôler le nombre d'instances d'une classe présent à un moment
donné. C'est souvent très pratique pour les classes sans état et effectuant toujours les
mêmes traitements. Un singleton est construit grâce à des méthodes de classes. Ces méthodes
appartiennent à une classe et peuvent être accédées indépendamment de l'objet.
Le Builder ou Monteur est une classe offrant des moyens de construction d'un objet. Par
exemple, pour construire un dessin il faut ajouter des points, des lignes, des cercles.... Il ne
doit pas être confondu avec la Fabrique. On peut exploiter les Monteurs en complément d'une
Fabrique. Un Fabrique utilise alors le Builder pour "monter" l'objet retourné.
2.3. Les modèles de structure
Ces modèles de conception tentent de composer des classes pour bâtir de nouvelles
structures. Ces structures servent avant tout à ne pas gérer différemment des groupes
d'objets et des objets uniques. Tout le monde en utilisant un logiciel de dessin vectoriel est
amené à grouper des objets. Les objets ainsi conçus forment un nouvel objet que l'on peut
déplacer, et manipuler sans avoir à répéter ces opérations sur chaque objet qui le compose.
On obtient donc une structure plus large mais toujours facilement manipulable.
L'Adapteur ou Adapter est un moyen commode de faire fonctionner un objet avec une
interface qu'il ne possède pas. L'idée est de concevoir une classe supplémentaire qui se
charge d'implémenter la bonne interface (L'Adapteur) et d'appeler les méthodes
correspondantes dans l'objet à utiliser (L'adapté).
Assez proche de l'Adapteur, le Proxy cherche à ajouter un niveau de redirection entre l'appel
d'une méthode d'un objet et l'action associée. A cet effet, on construit une nouvelle classe
implémentant l'interface de l'objet à manipuler et déportant toutes les actions sur un autre
objet implémentant la même interface. Ce type de structure vise à pouvoir changer l'objet
cible sans changer l'objet source (manipulé).
Les Proxy sont trés utilisés pour la gestion d'objets distribués (protocole RMI en Java par
exemple). L'idée étant de construire des Proxy capable de communiquer avec des objets
distants (usage de la sérialisation en Java) sans que l'exploitant fasse de différences entre
un accès locale ou un accès distant.
Permet de modifier le comportement d'un objet lorsque son état est modifié. Tout est mis en
place pour donner l'impression que l'objet lui-même a été modifié.
Le modèle Composite cherche à éliminer toute différence entre un groupe d'objets et un
objet. Il s'agit d'une démarche récurrente valable pour tous les problèmes qui font émerger
de nouvelles structure par association. L'exemple le plus simple étant celui du groupe
d'objets dans un logiciel de dessin (on groupe tous les objets ensembles).
La manière la plus simple pour gérer ces modèles est l'exploitation d'une interface unique
pour les éléments simples et l'élément "composé".
L'utilisation d'une interface commune limite les besoins de tests de chaque objet, ici tous les
objets sont vus de la même manière.
On rencontre cette exploitation dans les arbres DOM avec les documents XML. Un
document XML est lui-même une forme de noeud ce qui permet de créer du chainage de
documents très facilement.
2.4. Les modèles de comportement
Le modèle de comportement simplifie l'organisation d'exécution des objets. Typiquement,
une fonction est composée d'un ensemble d'actions qui parfois appartiennent à des
domaines différents de la classe d'implémentation. On aimerait donc pouvoir "déléguer"
certains traitements à d'autres classes. D'une manière générale, un modèle de de
comportement permet de réduire la complexité de gestion d'un objet ou d'un ensemble
d'objet.
L'Itérateur ou Iterator est le plus commun des modèles de comportement. L'idée étant de
limiter la vision d'une collection par un utilisateur. Typiquement une collection contient un
ensemble d'objets stockés par différentes méthodes (un tableau, un vecteur...), l'exploitant
qui accède au contenu de la collection ne souhaite pas être concerné par cette manière de
gérer les objets. La collection offre donc un point d'accès unique sous la forme d'une
interface Iterator.
Cet exemple comprend un itérateur pour la collection CanvasImpl qui contient des objets de
type GraphicElement. Ces objets sont stockés dans un tableau, un itérateur ArrayIterator
parcourt le tableau et offre chaque élément contenu dans la collection par la méthode
getNextElement. Si plus tard, on désire changer de méthode de stockage des objets pour
des raisons de performances ou de coûts mémoire, il suffira de réaliser une nouvelle classe
implémentant l'interface Iterator.
Un Template ou Patron de méthode est très utilisé dans la conception objet. Ce modèle
utilise simplement les mécanismes de surcharge pour déléguer à d'autres classes certaines
parties d'un algorithme. L'idée ressemble un peu au modèle Builder sauf qu'ici, il sert à
construire un traitement et non un objet.
Définit une dépendance entre objets de telle manière que lorsque l’un des objets change
d’état, tous les autres objets dépendants sont avertis et mis à jour automatiquement.
Modèle-Vue-Contrôleur (MVC) est le pattern introduit par les inventeurs de Smalltalk pour
encapsuler certaines données ensemble avec leur traitement (le modèle), et les isoler de
l'interaction avec l'utilisateur (contrôleur) et la présentation de ces données (la vue).
Le paradigme MVC est un schéma de programmation qui propose de séparer une
application en 3 parties :
- Le modèle, qui permet les traitements métiers de l'application et l'accès aux sources
de données (fichiers, bases de données, systèmes d'information d'entreprise, …)
auxquelles est associée l'application.
- La vue, qui représente l'interface utilisateur.
- Le contrôleur, qui gère la synchronisation entre la vue et le modèle. Le contrôleur
réagit aux actions de l’utilisateur en effectuant les actions nécessaires sur le modèle.
Le contrôleur surveille les modifications du modèle et informe la vue des mises à jour
nécessaires.
Dans l'organisation logicielle MVC 2, le contrôleur est un servlet unique, en classe et en
instance. Les contrôleurs deviennent essentiellement des contrôleurs du dialogue entre
l'utilisateur et les objets métiers.
Dans ce modèle, le cycle de vie d'une requête est le suivant :
- Le client envoie une requête à l'application. La requête est prise en charge par le servlet
d'entrée.
- Le servlet d'entrée analyse la requête et réoriente celle-ci vers un contrôleur adapté.
- Le contrôleur sélectionné par le servlet d'entrée est responsable de l'exécution des
traitements nécessaires à la satisfaction de la requête. Il sollicite les objets métiers lorsque
nécessaire.
- Les objets métiers fournissent des données au contrôleur.
- Le contrôleur encapsule les données métiers dans des JavaBeans, sélectionne la JSP qui
sera en charge de la construction de la réponse et lui transmet les JavaBean contenant les
données métier.
- La JSP construit la réponse en faisant appel aux JavaBeans qui lui ont été transmis et
l'envoie au navigateur.
- Lorsque nécessaire, pour le traitement d'erreurs essentiellement, le servlet d'entrée traite
la requête directement, sélectionne la JSP de sortie et lui transmet par JavaBean les
informations dont elle a besoin.
- La JSP construit la réponse en faisant appel aux JavaBeans qui lui ont été transmis et
l'envoie au navigateur. Lorsque nécessaire, pour le traitement d'erreurs essentiellement, le
servlet d'entrée traite la requête directement, sélectionne la JSP de sortie et lui transmet par
JavaBean les informations dont elle a besoin.
La figure ci-dessus représente une implémentation du paradigme MVC avec les technologie
jsp/servlet
2.6. Les design-pattern J2EE
(Livre : « Core J2EE Pattern » p123)
Il existe un catalogue des design-pattern spécifiques à J2EE :
| Tiers |
Nom du pattern |
| Tiers Présentation |
“Intercepting Filter” “Front Controller” “View Helper” “Composite View”
“Service to Worker” “Dispatcher View” |
| Tiers Business |
“Business Delegate” “Value Object” “Session Facade” “Composite Entity”
“Value Object Assembler” “Value List Handler” “Service Locator” |
| Tiers d’intégration |
“Data Access Object” “Service Activator” |
2.6.1. Liens entre les différents design-pattern
2.6.2. Pattern du Tiers Présentation
| Pattern Name |
Synopsis |
| Intercepting Filter |
Facilitates preprocessing and post-processing of a request. |
| View Helper |
Encapsulates logic that is not related to presentation formatting into Helper components. |
| Composite View |
Creates an aggregate View from atomic subcomponents. |
| Service To Worker |
Combines a Dispatcher component with the FrontController and View Helper Patterns. |
| Dispatcher View |
Combines a Dispatcher component with the FrontController and View Helper Patterns,
deferring many activities to View processing. |
2.6.3. Pattern du Tiers Business
| Pattern Name |
Synopsis |
| Business Delegate |
Decouples presentation and service tiers, and provides a façade and proxy interface to the services. |
| Value Object |
Facilitates data exchange between tiers by reducing network chattiness. |
| Session Facade |
Hides business object complexity; centralizes workflow handling. |
| Composite Entity |
Represents a best practice for designing coarse-grained entity beans
by grouping parent-dependent objects into a single entity bean. |
| Value Object Assembler |
Assembles a composite value object from multiple data sources. |
| Value List Handler |
Manages query execution, results caching, and results processing. |
| Service Locator |
Encapsulates complexity of business service lookup and creation; locates
business service factories. |
2.6.4. Pattern du Tiers Integration
| Pattern Name |
Synopsis |
| Data Access Object |
Abstracts data sources; provides transparent access to data. |
| Service Activator |
Facilitates asynchronous processing for EJB components. |
|
