IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Les applications J2EE et les Frameworks

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


2. Les design-patterns



2.1. Introduction


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.


2.2.2. Singleton


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.


2.2.2. Builder


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.


2.3.1. Adapter


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


2.3.2. Proxy


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.


2.3.3. Composite


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.


2.4.1. Iterator


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.


2.4.2. Template


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.


2.4.3. Observer


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.


2.5. Le modèle MVC


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 :

  1. Le client envoie une requête à l'application. La requête est prise en charge par le servlet d'entrée.
  2. Le servlet d'entrée analyse la requête et réoriente celle-ci vers un contrôleur adapté.
  3. 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.
  4. Les objets métiers fournissent des données au contrôleur.
  5. 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.
  6. La JSP construit la réponse en faisant appel aux JavaBeans qui lui ont été transmis et l'envoie au navigateur.
  7. 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.
  8. 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.


Copyright(c) 2004 ALVARO Véronique.
Ce document issu de http://www.developpez.com est soumis à la licence GNU FDL traduite en français ici.

Mes articles :
Les applications J2EE et les Frameworks
Article sur Jonas
Les autres ressources :
Tous les cours Java
La FAQ Java
Les forums java, j2ee, JBuilder, Eclipse, Autres outils pour java.