Qu'est-ce qu'un design pattern ?
Des solutions éprouvées à des problèmes récurrents de conception : ce qu'est (et n'est pas) un patron, son histoire et pourquoi l'apprendre.
Avant de plonger dans les patrons que ce livre va dérouler, il faut s'accorder sur un point de départ : qu'est-ce, au juste, qu'un patron de conception ? Le mot est entouré d'un halo intimidant. On l'imagine réservé aux architectes logiciels chevronnés, gravé dans des ouvrages austères. La réalité est bien plus modeste, et bien plus rassurante.
Un patron de conception (design pattern) est une solution typique à un problème qui revient souvent en conception logicielle. Ce sont des sortes de plans pré-dessinés que vous adaptez pour résoudre un problème récurrent dans votre code. Avant d'aborder leur mécanique au fil des prochains chapitres, ce chapitre pose les fondations : ce qu'est un patron, ce qu'il n'est pas, d'où l'idée vient, comment on les classe, et surtout pourquoi prendre le temps de les apprendre.
Un patron n'est pas un bout de code
Voici la confusion la plus tenace, et la plus importante à dissiper d'emblée. Un patron n'est pas un morceau de code que l'on copie-colle, comme on importerait une fonction toute faite ou une bibliothèque. Vous ne pouvez pas « trouver » un patron et le coller dans votre programme.
Un patron est un concept général, un plan pour résoudre un problème particulier. Vous suivez ses détails et vous implémentez une solution qui colle aux réalités de votre propre programme. Deux applications du même patron, dans deux projets différents, peuvent produire un code radicalement différent.
Patron contre algorithme : la recette et le plan d'architecte
On confond souvent patrons et algorithmes, parce que les deux décrivent des solutions typiques à des problèmes connus. La distinction est pourtant décisive.
Un algorithme définit toujours un ensemble clair d'actions permettant d'atteindre un but. Un patron est une description bien plus haut niveau d'une solution. L'analogie de Shvets est lumineuse :
- Un algorithme ressemble à une recette de cuisine : des étapes précises et ordonnées pour parvenir à un résultat. Suivez-les à la lettre et vous obtenez le plat.
- Un patron ressemble davantage à un plan d'architecte (blueprint) : vous voyez à quoi ressemble le résultat et quelles sont ses propriétés, mais l'ordre exact de la réalisation reste à votre main.
À retenir
Retenez cette image : la recette se suit, le plan s'interprète. Si vous cherchez à appliquer un patron en recopiant mécaniquement un exemple sans comprendre le problème qu'il résout, vous tenez la recette par le mauvais bout. Un patron se comprend, puis s'adapte.
De quoi se compose la description d'un patron ?
La plupart des patrons sont décrits de façon très formelle, afin qu'on puisse les reproduire dans une multitude de contextes. Une description de patron comporte habituellement les sections suivantes :
- L'intention (intent) décrit brièvement à la fois le problème et la solution.
- La motivation explique plus en détail le problème et la solution que le patron rend possible.
- La structure des classes montre chaque partie du patron et la façon dont elles sont reliées.
- Un exemple de code dans un langage de programmation populaire facilite la saisie de l'idée.
Certains catalogues ajoutent d'autres détails utiles : l'applicabilité du patron (quand l'utiliser), les étapes d'implémentation et les relations avec les autres patrons. C'est précisément cette ossature — intention, problème, solution, exemple, applicabilité — que nous suivrons pour chaque patron dans les chapitres suivants.
Note
Cette structure formelle n'est pas de la bureaucratie : c'est ce qui transforme une bonne idée ponctuelle en un outil partageable. Sans description rigoureuse, un patron resterait un savoir tacite, transmis de bouche-à-oreille et déformé à chaque passage.
Qui a inventé les patrons ?
La question est bonne, mais pas tout à fait exacte, comme le souligne Shvets. Les patrons ne sont pas des concepts obscurs et sophistiqués — bien au contraire. Un patron n'est pas inventé, il est découvert. Ce sont des solutions typiques à des problèmes courants de conception orientée objet. Quand une même solution se répète encore et encore à travers des projets variés, quelqu'un finit par lui donner un nom et par la décrire en détail. Voilà, en substance, comment un patron émerge.
De l'urbanisme au logiciel
Le concept de patron a d'abord été décrit par l'architecte Christopher Alexander, dans A Pattern Language: Towns, Buildings, Construction. Le livre décrit un « langage » pour concevoir l'environnement urbain. Les unités de ce langage sont des patrons : ils peuvent décrire la hauteur idéale des fenêtres, le nombre d'étages d'un bâtiment, la taille des espaces verts d'un quartier, et ainsi de suite.
L'idée a été reprise par quatre auteurs : Erich Gamma, John Vlissides, Ralph Johnson et Richard Helm. En 1995, ils publièrent Design Patterns: Elements of Reusable Object-Oriented Software, où ils appliquèrent le concept de patron à la programmation. L'ouvrage présentait 23 patrons résolvant divers problèmes de conception orientée objet et devint très vite un best-seller. À cause de son titre à rallonge, on prit l'habitude de l'appeler « le livre de la bande des quatre » (gang of four), bientôt raccourci en « le livre du GoF ».
Depuis, des dizaines d'autres patrons orientés objet ont été découverts, et l'« approche par patrons » a essaimé dans bien d'autres domaines de la programmation, au-delà de la seule conception orientée objet.
Comment classe-t-on les patrons ?
Les patrons diffèrent par leur complexité, leur niveau de détail et leur échelle d'application au système conçu. Shvets propose l'analogie de la construction routière : on peut rendre un carrefour plus sûr en installant quelques feux tricolores, ou en bâtissant tout un échangeur à plusieurs niveaux avec passages souterrains pour piétons. Tout est question d'échelle.
À ses deux extrémités, on trouve :
- Les idiomes : les patrons les plus élémentaires et bas niveau. Ils ne s'appliquent généralement qu'à un seul langage de programmation.
- Les patrons architecturaux : les plus universels et haut niveau. On peut les implémenter dans pratiquement n'importe quel langage et, contrairement aux autres, ils servent à concevoir l'architecture d'une application entière.
Les trois familles par intention
Surtout, tous les patrons peuvent être classés selon leur intention, ou leur finalité. Ce livre couvre trois grands groupes, qui structureront toute la suite de notre parcours.
| Famille | Intention | À quoi ça sert |
|---|---|---|
| Créationnels (creational) | Fournir des mécanismes de création d'objets. | Augmenter la flexibilité et la réutilisation du code existant en découplant le « comment » de la création. |
| Structurels (structural) | Assembler objets et classes en structures plus grandes. | Composer des objets en gardant les structures flexibles et efficaces. |
| Comportementaux (behavioral) | Gérer la communication entre objets. | Répartir efficacement les responsabilités entre les objets. |
Astuce
Une façon simple de mémoriser les trois familles : les créationnels répondent à « comment je fabrique mes objets ? », les structurels à « comment je les assemble ? », et les comportementaux à « comment je les fais dialoguer et qui fait quoi ? ». Chaque chapitre de ce livre se rattache à l'une de ces trois questions.
Pourquoi apprendre les patrons ?
Soyons honnêtes, comme l'est Shvets : vous pourriez très bien exercer le métier de programmeur pendant des années sans connaître un seul patron. Beaucoup le font. Vous en implémentez d'ailleurs probablement déjà certains sans le savoir. Alors pourquoi investir du temps à les étudier ? Deux raisons solides.
Une boîte à outils de solutions éprouvées
Les patrons forment une boîte à outils de solutions testées et éprouvées face à des problèmes courants de conception. Même si vous ne rencontrez jamais directement ces problèmes, les connaître reste utile : cela vous apprend à résoudre toutes sortes de difficultés à l'aide des principes de la conception orientée objet. C'est un entraînement à penser la conception, autant qu'un catalogue de recettes.
Un vocabulaire commun
Les patrons définissent un langage commun que vous et vos coéquipiers pouvez utiliser pour communiquer plus efficacement. Vous pouvez dire : « Oh, utilise donc un singleton pour ça », et tout le monde comprend l'idée derrière votre suggestion. Pas besoin d'expliquer ce qu'est un singleton si chacun connaît le patron et son nom.
Astuce
Ce gain de vocabulaire est sans doute le bénéfice le plus immédiat au quotidien. « Mettons un observateur (Observer) ici », « cette classe est une fabrique (Factory) », « enveloppons-le dans un décorateur (Decorator) » : trois mots remplacent un quart d'heure d'explications au tableau.
Une mise en garde honnête
L'enthousiasme pour les patrons a un revers, et il serait malhonnête de le taire. Le danger principal est la sur-ingénierie (over-engineering) : appliquer un patron parce qu'on vient de l'apprendre, et non parce que le problème l'exige.
Un patron mal motivé alourdit le code d'abstractions inutiles, le rend plus difficile à lire et complique sa maintenance. Avoir un marteau ne transforme pas chaque problème en clou. La bonne démarche est toujours la même : partez du problème, pas du patron. Identifiez d'abord la douleur concrète — un code rigide, dupliqué, impossible à étendre — et ne convoquez un patron que s'il y répond précisément.
Attention
Certains patrons ne sont que des béquilles pour des lacunes de langages anciens. Des fonctionnalités absentes en C++ ou en Java des années 1990 sont aujourd'hui natives dans des langages plus modernes (fonctions de première classe, mixins, types algébriques). Avant d'implémenter un patron à la main, vérifiez que votre langage ne l'offre pas déjà gratuitement. Un patron qui combat le langage plutôt qu'un vrai problème de conception est un mauvais signe.
À retenir
- Un patron est un plan, pas un algorithme : il décrit un concept général à adapter, là où un algorithme dicte des étapes précises. La recette se suit, le plan s'interprète.
- Un patron ne se copie-colle pas : deux implémentations du même patron, dans deux projets, peuvent donner un code très différent.
- Une description formelle comporte intention, motivation/problème, structure, exemple de code, et souvent l'applicabilité — l'ossature qu'on suivra pour chaque patron.
- L'idée vient de l'architecture (Christopher Alexander), puis fut appliquée au logiciel par le Gang of Four en 1995, avec ses 23 patrons fondateurs.
- Trois familles selon l'intention : créationnels (créer des objets), structurels (les assembler), comportementaux (les faire communiquer).
- Deux bonnes raisons d'apprendre : une boîte à outils de solutions éprouvées et un vocabulaire commun en équipe — mais gare à la sur-ingénierie : partez toujours du problème, jamais du patron.