Cet article a pour objectif de présenter les Design Patterns. Il expose un historique succinct, la définition et la représentation des Design Patterns, leurs avantages et leurs organisations.


Différents termes

Tout d’abord, les Design Patterns ont plusieurs noms francisés qui permettent de les désigner. Les plus courants sont ’motif de conception’, ’modèle de conception’ ou encore ’patron de conception’. La signification de ces termes est équivalente. Cependant, suivant les goûts des personnes, certains termes apparaissent plus parlants que d’autres.


Historique

Livre de référence sur les Design patterns

L’origine des Design Patterns remonte au début des années 70 avec les travaux de l’architecte Christopher Alexander. Celui-ci remarque que la phase de conception en architecture laisse apparaître des problèmes récurrents. Il cherche alors à résoudre l’ensemble de ces problèmes liés à des contraintes interdépendantes (solidité de la structure, étanchéité...). Pour cela Alexander établi un langage de 253 patterns, qui couvrent tous les aspects de la construction (comme par exemple la façon de concevoir une charpente).

Dans les années 90, l’idée de Christopher Alexander va être reprise et étendue au domaine de la conception des logiciels. Le concept de Design Pattern est développé dans un ouvrage publié en 1995 par le ’Gang of Four’. Cette équipe qui regroupe Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides intitule ce livre ’Design Patterns : Elements of Reusable Object-Oriented Software’. Celui-ci présente 23 Design Patterns qui font aujourd’hui référence dans le monde de l’informatique.


Définition

Un Design Pattern est une solution à un problème récurrent dans la conception d’applications orientées objet. Un patron de conception décrit alors la solution éprouvée pour résoudre ce problème d’architecture de logiciel. Comme problème récurrent on trouve par exemple la conception d’une application où il sera facile d’ajouter des fonctionnalités à une classe sans la modifier (voir la solution du Design Pattern Visiteur). A noter qu’en se plaçant au niveau de la conception les Design Patterns sont indépendants des langages de programmation utilisés.


Représentation d’un patron de conception

Les Design Patterns sont représentés par :

  • Nom : qui permet de l’identifier clairement
  • 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


Les avantages

L’utilisation des Design Patterns offre de nombreux avantages. Tout d’abord cela permet de répondre à un problème de conception grâce à une solution éprouvée et validée par des experts. Ainsi on gagne en rapidité et en qualité de conception ce qui diminue également les coûts.

De plus, les Design Patterns sont réutilisables et permettent de mettre en avant les bonnes pratiques de conception.

Les Design Patterns étant largement documentés et connus d’un grand nombre de développeurs ils permettent également de faciliter la communication. Si un développeur annonce que sur ce point du projet il va utiliser le Design Pattern Observateur il est compris des informaticiens sans pour autant rentrer dans les détails de la conception (diagramme UML, objectif visé...).


Organisation des patrons de conception

Les patrons de conception sont classés en trois catégories :

  • Création : ils permettent d’instancier et de configurer des classes et des objets.
  • Structure : ils permettent d’organiser les classes d’une application.
  • Comportement : ils permettent d'organiser les objets pour qu’ils collaborent entre eux.


Cette petite introduction sur les Design Patterns touche à sa fin. En parcourant ce site vous en apprendrez plus sur ce sujet. Mais attention une fois qu’on a touché aux Design Patterns il est difficile de s’en passer ;)

Commentaires

Je débute en programmation Java et les Design Patterns. Bravo pour cette présentation claire et concise. Vos descriptions des Design Patterns semblent être tout aussi intéressantes (pour l’instant je n’ai lu que 3 modèles de conception) et la mise en application avec le code que vous fournissez est très simple. Je vais poursuivre la lecture ...

Bravo, c’est très clair et très instructif ! J’aurais voulu lire une description pour chaque design pattern existant, mais les trois qui sont exposés valent à ce site d’être déjà qualifié de référence !

bonsoir : c’est un tres bon resume sur les patterns langages de l’architecte mathematicien ,informaticien :c’est un tout qui fait une partie et une partie qui fait le tout en trouve la solution de l’enigme de relation meronomie et la relation holonymie dans la personnalite de mr christoper Alexander.

Bonjour,

L’approche semble plutôt bonne et la lecture plutot agréable (les exemples sont toutefois un peu long à mon gout) pour ce sujet qui est assez délicat à traiter. La rigueur est appréciable, peu d’articles (wikipédia notamment) répondent systématiquement et clairement aux 4 notions clés des designs patterns (nom, pb, solution et conséquence).

En revanche attention à l’orthographe (Dans le paragraphe d’introduction "Il faut donc que celui-ci soit déclarer explicitement en privé" => "déclaré", dans décorateur "dés la conception" => "dès", "qui peuvent être ajouter aux desserts" => "ajoutés"), et j’ai un gros doute sur le fait que « synchronized » soit apparu en Java 1.5. Déjà en 1.4.2 je l’utilisais.

En tout cas merci pour ce travail

Bonjour je voudrais savoir comment on peut gerer les sessions avec Design Patterns ?

je developpe une application web ( JSP struts ) et pour le couche d’acces aux base de données j’utlise Design Pattern

Merccci bien

Merci pour ta réponse. et je profite pour te remercier pour ce site que tu as mis en ligne. Moi je suis un jeune développeur j2ee(à peine 06mois d’expérience). Si je peux contribuer à l’évolution du site je reste disponible.

Je trouve votre travail génial et même hyper génial; en tout cas pour les francophones.

Merci.

Bonjour,

C'est vraiment un très bon site, les patterns sont vraiment très bien expliqués. Dommage qu'il n'y en a pas d'autres comme:

Strategy, Composite, Iterator, Template Method, Builder, Proxy, Adapter, Bridge, Mediator, Chain of responsibility, memento, command, prototype, state, visitor, flyweight, facade, interpreter

Vivement la suite, et bonne continuation ;)

Ajouter un commentaire