Les Design Patterns (abréviation DP) sont présentes dans l'industrie, ont droit à des articles innombrables, des pour, des contre, suscitent l'excitation des débutants... Voilà encore un bon candidat pour les faux Graals.

Les Design Patterns (ou Patrons de conception) désignent une notion générale en programmation objet. Ils désignent souvent abusivement le livre « Design Patterns -- Elements of Reusable Object-Oriented Software » du « Gang of Four ». Abusivement car cela tant à limiter le concept à ce qui y est décrit et de la manière dont c'est décrit.

La notion de Design Pattern, qui vient de l'architecture, est de définir et nommer des solutions de conception d'un programme.

Une précision importante avant de continuer : l'existence de ces solutions de conception précède leur définition.

Du premier point, on tire que ce n'est pas le livre du GoF qui a inventé les patrons qu'il décrit. Cela signifie aussi que le livre décrit une connaissance à sa date de publication (1995) et que les travaux en architectures informatique ne se sont pas arrêtés à cette date.

Ce que permettent avant tout les DPs, c'est de fluidifier les échanges entre informaticiens, que ce soit dans des discussions directes ou par travail conjoint sur un programme.

Ainsi, un programmeur n'aura pas à conseiller de faire « une classe qui offre une méthode qui renvoie un objet d'un type déterminé par un paramètre » mais parlera de « fabrique » (ou factory). L'interlocuteur parlant le même langage saura de quoi il est question.

De même, un programmeur qui voit une classe nommé « EntityFactory » se doutera (et vérifiera rapidement en lisant le code) qu'il a affaire à une fabrique d'objets de type « entity ». Lui reste à connaître Entity, mais il ne perd pas de temps sur la classe Factory.

Apprendre les Design Patterns

Lorsqu'un débutant découvre les Design Patterns, il pense avoir trouvé là leGraal. Une sorte de livre de recette qui donnerait la solution à chaque problème de conception. Lire et intégrer le livre, pense-t-il, fera de lui un expert de l'architecture informatique.

Pourtant, s'il lit le livre dès le début et ne se contente pas des descriptions des différentes patrons, il verra l'avertissement des auteurs. De même que l'existence des DPs a précédé leur formalisation, il est préférable d'avoir eu à résoudre un problème et de chercher sa solution avant d'en lire sa formalisation.

En d'autres termes, après la lecture de tout un catalogue de DPs, il est fort probable que les seuls retenus soient ceux que l'on a été amené à appliquer avant d'en connaître le nom.

Lire une fois leur description permet cependant de les avoir dans un coin de la tête pour provoquer la bonne intuition le jour où un problème fait que l'un d'eux pourrait être utile. Il sera temps, à ce moment là, de revenir sur la formalisation complète pour confronter la solution que l'on a trouvé au DesignPattern.

Attention : cela ne veut pas dire que si la solution trouvée diffère, elle est forcément mauvaise. Les différences seront à évaluer consciencieusement.

Ce qui nous amène au point suivant.

Formalisation et limitation

J'ai pu lire quelques articles expliquant que les DPs étaient mauvais car ils limitaient la pensée. Pour certain, c'est car ils s'occupent de problèmes trop typés C++, pour d'autres, la formalisation limite la recherche de solutions dans un ensemble restreint de ce qui a déjà été défini.

Dans les deux cas, l'erreur est de se focaliser sur l'existence du livre. Il est vrai que l'architecture d'un programme n'est jamais complètement indépendante du langage, fut-il orienté objet, sur lequel il repose. Il existe cependant des similitudes qui font que les patterns décrits par le livre,s'ils s'appliquent bien au C++, ne sont pas entièrement invalidés pour d'autres langages.

Si un langage de programmation offre des outils qui permettent de résoudre élégamment un problème de manière différente que les DPs décrits par le livre,cela n'invalide par le concept des DPs, ca le renforce en y ajoutant une entrée.

De même en ce qui concerne la formalisation qui empêcherait de sortir de limites définies il y a plus de 10 ans. C'est croire que le livre fixe l'ensemble des DPs alors qu'il fait état de la connaissance à ce moment là. À aucun moment cela ne fixe des limites à la recherche de nouvelles solutions.

Le lecteur aura peut-être remarqué que cette critique contre les DesignPatterns ressemble fortement à celle exposée contre UML : un langage limiterait la nouveauté, la liberté de recherche.

Un langage commun permet de fluidifier les échanges. Lorsqu'il est formel, il permet d'éviter des erreurs, de savoir de quoi on parle. Mais un langage offre des briques pour construire par dessus. Un langage est dynamique, encore plus qu'une langue vivante qui elle aussi subit des modifications en fonction de son utilisation, des besoins des locuteurs, de leurs habitudes.

Prenons un exemple du langage courant. Je dis « table ». Vous avez alors à l'esprit (je suppose) un objet composé d'une surface plane soutenue par des pieds. C'est un patron général qui ne limite pas le matériaux, le nombre de pieds, la forme, le procédé de fabrication.

Je peux préciser : table basse, table ronde, table en bois.

Et si « table » donne une réponse à la question d'un support d'objet à portée d'un humain assis, cela ne limite en aucun cas le choix d'autres concepts :bar, desserte, bureau ou même étagère sont d'autres solutions.

Il faut donc bien dissocier en premier lieu le concept général de DesignPattern du livre du GoF qui en décrit. Puis en second lieu ne pas considérer les patterns existants comme une connaissance figée.

L'attirance du singleton

« J'ai commencé à programmer mon moteur 3d, pour le moment, j'ai implémenté le pattern Singleton ». Cette phrase et ses dérivées, j'ai pu la voir des dizaines de fois dans des forums de discussion. Elle peut s'expliquer.

Comme dit précédemment, après une lecture exhaustive des descriptions deDesign Patterns, le lecteur retient surtout les cas qu'il a déjà rencontré.Or, le Singleton peut apparaître de prime abord comme une formalisation d'objet global. Le lecteur retrouve là quelque chose qui connaît : l'objet d'instance unique, atteignable de partout, en un mot, la globale qu'on lui a souvent dit de ne pas utiliser sans trop expliquer pourquoi. Mais là, c'est formel, c'est dans un bouquin de référence. Le lecteur retient le concept (une partie en tout cas, le Singleton n'est pas équivalent à une variable globale) et est heureux de pouvoir aborder son nouveau projet sous l'angle formel des Design Patterns.

Persuadé d'avoir trouvé son Graal, le lecteur va tenter d'implémenter d'autresDPs. Malheureusement, si l'usage d'un Singleton est immédiat et facilement compréhensible, si une implémentation naïve est possible très rapidement, il n'en est pas de même pour la plupart des autres patterns.

Effet d'un Graal, il peut y avoir alors rejet de toute la formalisation : ça ne sert pas, c'est de la théorie mais en pratique, on n'en a pas besoin, ça me limite,...

Nous voilà avec le schéma du faux Graal.

Avec l'expérience et en y revenant de temps en temps, en rencontrant progressivement le vocabulaire dans des articles ou en lisant des sources, en les confrontant aux solutions trouvées en réponse à ses problèmes, la valeur des Design Patterns se fait alors sentir.

Conclusion

« Programmeur » est un mot vaste et qui regroupe beaucoup de métiers différents, parfois se recouvrant. Tous les programmeurs ne sont pas des architectes. Mais pour les architectes et ceux qui ont besoin de notions d'architectures (je serais tenté de dire : tous !), connaître le vocabulaire des Design Patterns n'est pas quelque chose à mettre de côté.

Il est inutile, voire néfaste, de vouloir les apprendre par cœur, d'un coup,lorsque l'on débute la programmation. Mais en avoir connaissance et y confronter ses solutions est essentiel.