3.1.1. Les patrons de conception

En génie informatique, un patron de conception (design pattern en anglais) [Alexander et al, 1977] est un concept issu de la programmation orientée objet, destiné à résoudre les problèmes récurrents [Rieu et al, 1999].

Ce sont des solutions standards pour répondre à des problèmes d'architecture et de design des logiciels. À la différence d'un algorithme qui s'attache à décrire d'une manière formelle comment résoudre un problème particulier, les design patterns, décrivent des procédés de conceptions généraux. On peut considérer un design pattern comme une formalisation de bonnes pratiques, ce qui signifie qu'on privilégie les solutions éprouvées (un design pattern n'est considéré comme « prouvé » qu'une fois qu'il a été utilisé avec succès dans au moins trois cas).

Il ne s'agit pas de fragments de code, puisque les patrons de conception sont le plus souvent indépendants du langage de programmation, mais dépendants d'une méthode de conception, c’est-à-dire d'une manière standardisée de résoudre un problème qui s'est déjà posé par le passé. Le concept de design pattern a donc une grande influence sur l'architecture logicielle d'un système. Pour illustrer notre propos, nous pouvons reprendre l’exemple d’un patron de conception pour l’utilisation de l’outil CBR*Tools de l’INRIA qui présente la notion de Fabrique Abstraite.

Figure 16 : Exemple de patron de conception pour l’utilisation de l’outil CBR*Tools de l’INRIA
Figure 16 : Exemple de patron de conception pour l’utilisation de l’outil CBR*Tools de l’INRIA http://www-sop.inria.fr/axis/cbrtools/

On peut donc considérer le design pattern comme un outil de capitalisation de l'expérience appliquée à la conception logicielle. L'avantage de ces patterns est de diminuer le temps nécessaire au développement d'un logiciel, notamment en apportant des solutions déjà existantes à des problèmes courants de conception. Ils sont aussi utiles pour définir un vocabulaire commun entre les différents acteurs de l'écriture d'un logiciel. Cependant, nous avons besoin d’aborder un concept plus large prenant en compte les connaissances éprouvées mais également les autres types de connaissances. Ces patterns ne sont décrits que sous une forme générique, sans s'attacher aux détails du problème à résoudre. De plus, dans notre contexte, le spectre des connaissances échangées se veut plus large que la résolution de problèmes techniques en prenant en compte les aspects humains, prévisionnels, etc.

Les caractéristiques du patron qui nous intéressent sont la proposition de solutions documentées à des problèmes et ces solutions doivent avoir une dimension consensuelle.

Notes
2.

http://www-sop.inria.fr/axis/cbrtools/