Durant une conversation sur l'heure du lunch, l'étudiant que nous embauchons en a profité pour faire du name dropping d'un design pattern qu'il a appris récemment durant un de ses cours. Manifestement, il était un peu trop enthousiaste à expliquer qu'il a pu faire des expérimentations à ce sujet dans une portion d'un de nos projets. L'équation "étudiant + expérimentation + notion non-maitrisée" a déclenché un stack overflow dans ma tête. Mieux valait intervenir tout de suite sans quoi, c'est encore bibi qui devra réajuster le tout dans un avenir plus ou moins rapproché. Immédiatement, je l'ai interrompu en lui faisant remarquer que non seulement il utilisait le pattern dans un mauvais contexte, mais surtout qu'il valait mieux ne pas essayer d'en appliquer juste pour le plaisir, que le choix d'en utiliser un doit d'abord solutionner un problème.
Tous les jours, on crée des patterns sans s'en rendre compte. Ce n'est qu'en analysant le travail effectué qu'on peut les mettre en évidence et si nécessaire, les nommer. Certains semblent ne jurer que par la bible du GoF qu'ils élèvent au niveau de livre culte. Loin de vouloir dénigrer ce livre (que je possède), je reproche à ses adeptes le manque de jugement quant à la façon de les mettre en application. Des concepts solides mais souvent fort mal utilisés.
Pour bien les comprendre et les apprécier, il faut parfois s'être planté en optant pour une solution moins élégante et plus compliquée à implémenter (menant parfois au blasphème et des nuits blanches). Les patterns ne sont qu'une solution parmi tant d'autres et il en existe beaucoup plus qu'il y en a de documentés.
Le terme design patterns a magnifiquement été traduit par patrons de conception. Un patron, ça m'évoque un modèle utilisé pour confectionner des vêtements. Pour que ce modèle puisse exister, il y avait d'abord un prototype unique, complété à force d'essais et d'erreurs, qu'on souhaitait ensuite imiter et reproduire en contournant les obstacles rencontrés lors de la création originale. Quand on écrit du code sur mesure, il n'y a pas que les tailles Small, Medium, Large et surtout pas One Size Fits All. Même pour les patterns, on doit y apporter différentes altérations pour que ça s'imbrique à la perfection dans notre projet. Ce n'est jamais une solution définitive mais plutôt une piste à suivre en vue de la résolution d'un problème.
C'est une source d'inspiration pour créer sa propre recette. Bien sûr, on pourrait suivre les étapes à la lettre en mélangeant les ingrédients mesurés avec exactitude mais il y a parfois des contraintes qui nous forcent à adapter la formule à nos besoins. Après tout, il n'existe pas qu'une seule recette de sauce à spaghetti même si la base de sauce tomate représente 75% de la solution. Tel un chef de cuisine, on ajoute de la personnalité au 25% restant. Créativité. Inventivité.
Enfin, la meilleure analogie qu'on m'a donné sur les patrons de conception est de faire le lien avec une gamme musicale. Même si on connaît toutes les notes de la gamme, qu'on les joue toutes dans le même ordre et au même rythme, ça ne produira pas une musique agréable. On ne peut pas ouvrir un livre de référence sur les gammes, en choisir une, la jouer sur son instrument et espérer que le public l'appréciera. Au contraire, le résultat sera ennuyant et n'atteindra pas son objectif. Idem pour les Design Patterns. Il faut voir ce que propose le GoF comme une référence sur les gammes : un point de départ solide pour construire des solos mais c'est à nous de les appliquer et les adapter pour en faire de la bonne musique.
mardi 21 février 2012
2 réponses à "Le piège des design patterns"
S'abonner à :
Publier des commentaires (Atom)
Personnellement, j'aime bien les idées nouvelle dans les designs pattern, mais je vois ca plus comme un restaurant: bien que chaque cuisinier ait sa propre vision, il doivent quand même suivre la même recette!
Je crois que lorsque l'on choisit quelques structures, on doit s'y commiter. C'est à dire que chaque professionnel doit suivre la décision du groupe. On peut proposé de nouvelle approche, mais tout le groupe doit être d'accord, car c'est rarement une personnes seule qui assure la maintenabilité de l'application et sa flexibilité.
Bref, mes deux cennes :-p
Après, il peut être bon de rappeler le but original des design patterns : éviter de réinventer la roue (carrée) et résoudre, de la meilleure façon qui soit (du moins par ce qu'en dicte le GoF), des problèmes courants. Bref, faire simple, robuste et rapide pour un cas donné et bien défini.
Pour moi, il y a une règle de base : si vous devez complètement adapter un design pattern, alors soit vous n'en avez pas besoin, soit vous avez de grandes chances de vous planter.
En effet, comme les designs patterns répondent à des problèmes, les adapter va a l'encontre de la philosophie du truc, c'est comme essayer de faire rentrer des cubes dans un trou rond : c'est un antipattern. Dans ce cas, autant oublier le design pattern et réfléchir à une solution neuve qui nous évitera de nous cacher, en cas d'erreur, derrière la sempiternelle excuse du "c'est une question de contexte".