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

Souplesse et modularité grâce aux Design Patterns


précédentsommairesuivant

VI. Mise en œuvre

Cette section permet de donner une vue d'ensemble des différents patterns abordés dans cet article afin de se concentrer plus spécifiquement sur leur interaction et leur mise en œuvre.

VI-A. Séparation Instanciation/Données/Traitements

En Programmation Orientée-Objets « classique », on apprend que dans une classe, on a :

  1. Des constructeurs pour créer les instances de cette classe (ne pas oublier le destructeur, pour libérer la mémoire) ;

  2. Des attributs, les données que contiennent les objets ;

  3. Des méthodes, qui permettent d'accéder et de modifier ces données.

Changer l'un de ces éléments signifie modifier la liste des constructeurs, des attributs ou des méthodes, avec des répercussions sur l'ensemble de la hiérarchie des classes.

Avec les Design Patterns, il est possible de séparer très clairement ces 3 phases en 3 hiérarchies distinctes :

  1. L'instanciation peut se faire à l'aide d'une Factory Method ou d'une Abstract Factory, par exemple ;

  2. La hiérarchie des objets sert uniquement de support de données (attributs). Cette hiérarchie peut être constituée d'objets Composite et/ou Decorator ;

  3. Les traitements sur les données peuvent être faits au moyen de Visiteurs.

Création/Objets/Traitements
Séparation Création/Objets/Traitements

Les Design Patterns, permettent souvent ce genre de séparations. Ainsi le pattern MVC (Model-View-Controler, qui n'est pas un pattern du GoF, mais est issue du langage Smalltalk) permet de séparer le modèle (les données) de leurs représentation et interaction. Le pattern MVC est notamment repris dans les applications Java EE pour séparer les données et traitements (Model) de l'affichage de ces données (View). Le Controler sert à analyser les requêtes du client, à appeler le modèle correspondant avec la vue adéquate.

Pourquoi des telles séparations ? Pour rendre les modules plus indépendants (ex-: séparer les données métier de leur représentation en base) et ainsi faciliter leur développement. La séparation en modules facilite l'organisation en équipes : plusieurs équipes peuvent travailler sans interférer sur le travail des autres.

VI-B. Aspect modulaire des Design Patterns

Il est intéressant de remarquer que si les Patterns permettent le développement d'applications modulaires (par l'utilisation d'objets composites et/ou interchangeables), les Design Patterns eux-mêmes présentent un caractère modulaire.

En effet, pour un problème donné, les Design Patterns proposent souvent plusieurs solutions distinctes en présentant les avantages, les limitations, les contextes de mise en œuvre, etc.

Ainsi, pour différentes parties de l'application on a le choix entre plusieurs Patterns (interchangeables et parfois même combinables !) :

  • Représentation des données : Decorator / Composite / Strategy ;

  • Création des objets : Factory Method / Prototype / Builder ;

  • Ajout de traitements : Visitor ;

  • Gestion des objets distants : Proxy ;

  • Coordination des composants : Facade / Mediator.

Dans cet article, nous avons aussi vu la démarche utilisée avec les Design Patterns : pour un problème donné (ex. : mettre en œuvre des objets modulables), on a souvent plusieurs solutions possibles proposées par les Design Patterns. Chaque solution soulève éventuellement de nouvelles questions auxquelles on n'aurait pas forcément pensé de prime abord (ex. : la création et la gestion de ces objets), la réponse à ces questions pouvant se trouver dans d'autres Patterns.

Ainsi, de proche en proche, on construit une solution cohérente pour un problème donné, par assemblage de solutions existantes, reconnues et éprouvées.

C'est pour cela que l'on dit des Design Patterns qu'ils facilitent la transmission de savoir entre informaticiens expérimentés et débutants : les solutions exposées dans les Design Patterns sont connues du plus grand nombre, facilitent la communication, et tendent vers des solutions relativement standard et réutilisables dans différents contextes. Ce qui demande juste un peu de pratique, c'est d'apprendre à assembler ces différentes solutions afin d'obtenir un tout cohérent.


précédentsommairesuivant

Copyright © 2006 Pierre Caboche. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.