Souplesse et modularité grâce aux Design Patterns

Mine de rien, le contenu de cet article est assez dense pour le débutant (mais aussi pour les autres) :

• on aborde en introduction les limites de la programmation par simple héritage, surcharge et polymorphisme ;
  
  
• on présente les notions de Patterns et de modules ;
  
  
• on passe rapidement en revue quelques-uns des Design Patterns les plus utilisés ;
  
  
• on découvre le processus qui permet, par raisonnements successifs et de proche en proche, d'élaborer une solution quasi complète par assemblage de patterns ;
  
  
• on comprend un peu mieux ce que sont les Design Patterns, à quoi ils servent, comment les mettre en œuvre ;
  
  
• on comprend mieux la notion de modules, l'interchangeabilité, l'intérêt de la séparation entre données, traitements et instanciation.

Nous avons une définition plus précise (bien qu'encore incomplète) de ce qu'est un module :

• des modules peuvent être des éléments (le plus souvent interchangeables) capables de se combiner entre eux pour créer de nouveaux objets ou de nouveaux comportements (ex.: Composite, Decorator, Strategy) ;
  
  
• une organisation en modules permet de rendre les objets plus indépendants les uns des autres, ce qui facilite l'extension de l'application ainsi que le partage des tâches entre programmeurs (ex-: séparation Instanciation/Données/Traitements, séparation Model/View/Controler).

En résumé, deux aspects se dégagent de cet article :

1. L'aspect purement technique portant sur la mise en œuvre des Design Patterns (quels patterns et pour quoi faire ?) ;
2. L'aspect plus général sur la gestion de projets et l'organisation d'une application en modules indépendants.

À la lecture de cet article, vous devriez avoir une meilleure connaissance de ce que sont les Design Patterns, quel est leur intérêt, comment les mettre en œuvre. Toutefois il est nécessaire de garder à l'esprit que nous n'avons fait qu'un survol de certains patterns importants afin d'en exposer le principe et l'intérêt. Cette description ne peut en aucun cas se suffire à elle-même (il manque notamment des détails concernant l'implémentation, la discussion sur l'applicabilité et les limites de chaque pattern, etc.) et il est absolument indispensable de se documenter plus sérieusement sur chacun des patterns exposés (notamment ceux qui vous intéressent).

Pour cela, plongez-vous dans la lecture de Design Patterns: Elements of Reusable Object-Oriented Software par Gamma et al., qui est la référence dans le domaine. Quelques ressources sont également disponibles sur le site de developpez (voir liens externes).

Une fois ces connaissances acquises et assimilées, et après un peu de pratique sur l'utilisation des patterns (identification des problèmes, recherche des patterns adaptés, mise en œuvre de la solution), on comprend assez vite l'intérêt de telles solutions, qui peuvent paraître assez lourdes pour de petits programmes, mais qui deviennent quasiment incontournables dans des projets d'envergure réunissant plusieurs personnes.

Pour ceux qui souhaitent approfondir leur connaissance des Design Patterns, j'ai aussi écrit un article spécifiquement sur le pattern Etat.

Le livre Design Patterns (Gamma et al.), le livre de référence en version française.

Merci à Miles, wichtounet, Nip et jerome.petit pour la relecture de cet article.

Cet article au format PDF