Pourquoi je n'aime pas (trop) les design patterns

Bien sûr j'utilise les Design Patterns. Ils simplifient parfois la vie, et apportent des solutions standards et éprouvées à des problèmes logiciels récurrents. Ils ont beaucoup d'avantages, permettent d'éviter certaines erreurs, et standardisent le développement logiciel.

Je pourrais dire que je n'aime pas trop les Design Patterns parce qu'ils peuvent alourdir le code, parce qu'on peut contester l'efficacité de certains, ou encore parce qu'ils contribuent à un over engineering qui m'exaspère en plus en plus... Mais non. Les Design Patterns sont comme une boîte à outils, il fait savoir les utiliser correctement. On enfonce pas un clou avec un niveau à bulles (quoique...), tout comme on utilise pas un singleton pour un objet qui peut avoir plusieurs instances.

En fait, ce que je n'aime pas avec les Design Patterns, c'est la façon dont ils limitent la pensée, la réflexion, la créativité. Sous prétexte que certains ont déjà élaboré des solutions pour des problèmes courants, on ne se pose même plus la question, et on applique bêtement ce qu'on a appris. Les Design Patterns sont tellement reconnus qu'on n'ose pas les remettre en question, et on pense qu'en utilisant un Design Pattern, on ne peut pas vraiment se tromper. Du coup les développeurs ne voient plus les potentielles autres solutions, peut-être moins reconnues, mais pourtant plus adaptées au problème qui se pose.

Une fois qu'on a compris qu'un Design Pattern répondait à un problème, il est rare que l’on revérifie qu’il n’existe pas de meilleure solution si le même problème se représente. Or le contexte peut être différent, les objectifs du projet aussi. Nous avons l'habitude d'utiliser les Design Patterns, et cela nous fait croire qu'on détient LA solution. Les Design Patterns ne sont pas immuables, et ce n'est pas en nous limitant à leur utilisation qu'on pourra les faire évoluer.

L’habitude consiste à utiliser de façon inconsciente une connexion neuronale déjà existante. Elle est donc un redoutable facteur d’efficacité puisqu’elle permet de résoudre la plupart des problèmes de façon rapide et sans s’encombrer l’esprit. Cette efficacité et le caractère inconscient de l’efficacité en font un obstacle sournois à l’émergence d’idées nouvelles et fécondes. Même si on ne peut pas le faire tout le temps, il faut donc questionner les habitudes. Pourquoi continuer à faire comme ceci ou comme cela ? --- Une fourmi de 18 mètres, ça n'existe pas

Il faut connaitre les Design Patterns. Il faut les comprendre. Il faut les avoir manipulés. Il faut les maitriser. Mais il ne faut pas chercher à les utiliser. On ne devrait pas se demander "Existe-t-il un pattern qui me permette de résoudre ce problème ?", mais "Quelles sont les possibilités pour résoudre ce problème ?" Et alors, on envisage toutes les possibilités à égalité : les Design Patterns, les solutions Quick&Dirty, et les plus extravagantes. Et on peut alors choisir la solution la plus simple, la plus adaptée à notre problème.