À propos des Design Patterns

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 !

Tweet about this on TwitterShare on FacebookGoogle+Share on LinkedIn

7 réflexions au sujet de « À propos des Design Patterns »

  1. Tu peux corriger l’article wikipedia du coup… “reconnu comme bonne pratique en réponse à un problème de conception d’un logiciel. Il décrit une solution standard, utilisable dans la conception de différents logiciels”. Il y a peut-être un raccourci linguistique à se demander quel pattern on peut utiliser pour tel problème, mais de là à dire qu’on est à côté de la plaque…

  2. Bonjour Thomas,
    Je trouve cette vision sur les designs Patterns très intéressante.

    En effet je pense que la plupart d’entre nous s’orientent vers une définition plus classique des design patterns, telle que proposée par le GoF selon laquelle les design patterns représentent des solutions à des problèmes de conception connus et constituent une sorte de “boîte à outil”.

    En ce sens j’ai du mal à saisir le sens de la conclusion proposée. Le message est-il que nous devons accorder plus d’importance aux inconvénients ou avantages que peuvent conférer l’implémentation de certaines solutions (et ce grâce aux designs patterns) ?

    Merci de nous éclairer si possible.

  3. Bonjour à tous,

    A l’évidence, il y a eu comme un couac ici… cet “article” n’aurait pas dû être publié en l’état : il n’est absolument pas finalisé !!! Désolé, ce n’est qu’une ébauche, là.

    Je vais reprendre tout ça le plus rapidement possible et développer mon argumentation ; on ne peut quand même pas dire autre chose que… wikipédia (?) impunément 😉

  4. Bon article, plus qu’une boite à outils j’essaie d’expliquer aux devs junior que j’encadre que ce sont des façons de faire, des recettes, qu’il faut se les approprier pour développer des automatismes et étre créatif (créatif = tout le côté grisant du développement, qui permet de développer son propre style, etc..). Comparaison aussi avec l’alpiniste, qui utilise la bonne prise ou le bon piton en fonction de la difficulté mais chez qui rien n’est arbitraire : tout doit être choisi et doit pouvoir être justifié. D’où l’importance du ‘pourquoi’ par rapport au ‘comment’ et du “réféléchir avant d’agir”. Combien de développeurs débutant sont incapable de faire une phrase en français pour expliquer ce qu’ils essaient de faire, ou encore décrivent le cas particulier auquel ils sont confrontés sans essayer d’en faire un cas général (=> abstraction).

  5. Je ne sais pas si l’article a été revisité depuis sa publication anticipée; mais je ne suis pas d’accord avec ce qu’il indique aujourd’hui (“Les design patterns ne sont pas une boîte à outils. Ils sont un langage. “). Un design pattern, ce n’est pas un langage :-/

    Comme le dit Gengis, ce sont des recettes qui portent chacune un nom.

    Par parenthèse, le best-seller “Head first on Design patterns” est juste excellent.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


*