Avertissement : d’abord malencontreusement publié à l’état d’ébauche, cet article est maintenant dans sa forme aboutie. Merci de votre compréhension.
Les design patterns ne sont pas une boîte à outils. Ils constituent un langage. Le but d’un langage est de permettre la communication par le biais d’abstractions partagées. Autrement dit, un langage sert à évoquer ce qui n’est pas là, qui ne peut être simplement montré. En effet, nul besoin de mots pour désigner ce qui est présent (une destination, un danger) : un doigt (avec parfois un cri) suffit. Pour tout le reste, nous utilisons des mots désignant des concepts plus élaborés (le temps, les sentiments, des noms désignant des choses définies par ailleurs – les références). Un langage vous permet de comprendre de quoi il s’agit quand on vous invite au théâtre, quand on vous convoque à une réunion de travail ou encore quand on vous remet une liste d’instructions.
Chaque profession développe son propre vocabulaire non équivoque afin de désigner des notions spécifiques, précises et récurrentes. Que seraient les marins sans bâbord ni tribord ? Les architectes sans clef de voûte ? Les mécaniciens sans moteur à explosion ? La spécialisation est une caractéristique fondamentale du langage. En ce sens, on pourrait même aller jusqu’à dire que les langues mortes ne sont pas des langages. Le langage est avant tout pragmatique, adaptable. Plus son domaine d’application est récent ou dynamique, et plus il a besoin d’évoluer pour servir. Je vous invite à consulter, pour revenir aux design patterns, la série d’articles “Does the XXX Pattern Stand the Test of Time?” de Ayende Rahien (et, non, je ne sais pas pourquoi les anglophones aiment autant les majuscules).
En 1994 est paru le célèbre ouvrage du “gang of four” (GoF), et aujourd’hui la plupart des entretiens d’embauche d’informaticiens expérimentés abordent à un moment ou à un autre les design patterns. Et si le mot “objet” évoquera pour un informaticien la notion d’héritage, par exemple, il vaudrait mieux qu’il lui évoque la notion plus fondamentale d’encapsulation, c’est-à-dire d’état… C’est ainsi que les design patterns font de vous un bon informaticien : ils apportent à ceux qui en ont besoin, une définition précise et circonstanciée de la réalité qu’ils ont à appréhender. Et, pour moi, ce ne sont pas des outils. Votre ordinateur, votre IDE, sont des outils de travail. Prenons un autre exemple ; pour un chirurgien, le scalpel et les attelles sont des outils, mais la fracture est un concept, de même que la guérison. L’algorithme informatique, lui aussi, est un concept. Il est la cible de l’informaticien. L’informaticien n’a pas pour tâche de faire le métier des autres, on lui demande de l’informatiser. C’est-à-dire de le traduire en algorithme. Et pour cela, il utilise son savoir et son expérience afin de produire une solution. Chaque implémentation sera personnelle, en ce que le choix de telle ou telle tournure (boucle for, foreach…) peut ne pas changer le résultat final. Peu importe le remède employé, si vous êtes soigné dans des délais raisonnables, sans trop souffrir, n’est-ce pas ?
Selon moi, quand vous commencez par vous demander quel pattern vous allez utiliser pour résoudre un problème, et bien vous êtes déjà à côté de la plaque, d’une certaine façon. Imaginez-vous en train de présenter à votre équipe ce que vous avez l’intention de coder pour répondre à un besoin. Désigner (!) un pattern, c’est déjà aller trop vite ; on n’est pas là pour faire du name dropping. Ceux avec qui vous travaillez savent déjà que vous faites autorité, puisqu’ils vous écoutent. Et ils espèrent surtout que vous saurez appréhender les tenants et les aboutissants des solutions pragmatiques, évolutives, que vous envisagez. Quand un architecte prétend construire une arche, on ne lui demande pas s’il sait ce qu’est une clef de voûte. Ce n’est que lorsqu’une objection est levée que les design patterns viennent à votre secours : tel patron pourrait apporter ceci, mais tel autre permettrait d’éviter certains écueils dans la situation présente… Ils ne sont ni une baguette magique, ni un bouclier ; juste un sujet de discussion. Pour revenir à “la bible”, souvenons-nous que ce n’est pas un cours d’algorithmique, c’est un travail de collecte et d’étiquetage. Si, si, vérifiez !
Les design patterns sont là pour vous aider à appréhender les avantages et les limites des solutions qui se sont imposées à vous dans le contexte de votre application. Ils vous permettent de vous demander lors de vos développements si d’autres avant vous, ont déjà résolu le même type de problème (création, structure, comportement, etc.) et comment. Le catalogue des design patterns, vous indique plusieurs manières d’y parvenir, en fonction du contexte. C’est déjà beaucoup. Votre situation étant quand même particulière – sinon vous ne coderiez pas, vous utiliseriez une API – vous allez adapter la technique proposée. Si vous devez limer votre tournevis afin de visser quelque chose, autant le laisser sur place : ce n’est plus un outil, réutilisable, il est devenu une partie du meuble. Celui qui passera derrière vous devrait être capable de reconnaître votre pattern, n’ayez crainte, mais il est rare qu’il éprouve le besoin de le copier tel quel dans son propre code. Si une solution standard est apparue entre temps, ou si votre solution est devenue générique (joie : c’est la postérité), alors un petit coup de refactoring s’imposera de lui-même. Mais le concept, n’aura pas changé.
Pour conclure, je veux dire ici l’importance que j’accorde aux design patterns. On ne peut pas remettre un catalogue en question, pas plus qu’un dictionnaire, s’il dresse la liste des choses constatées. C’est simplement que je les trouve mal compris, la plupart du temps. D’ailleurs, leur importance ne cesse de croître à mesure que la quantité de code produit augmente. C’est l’étape qui suit la mise en conventions de codage ; une question de lisibilité, d’intelligibilité. Apprenez les design patterns, si vous faites de l’informatique. Découvrez de nouveaux design patterns, afin de les partager. Algorithmique, architecture orientée service, intégration d’entreprise, analyse statistique… ce ne sont pas les pistes qui manquent. Mais, S’IL VOUS PLAIT, n’enfermez pas les design patterns dans un écrin, une boîte à outils. Merci !
