"Patternite" : complexité inutile

Cependant, il faut oser un peu pour apprendre les patterns, donc il ne faut pas avoir peur de faire des erreurs dans les essais. Pour cette raison, j'aime la perspective donnée dans Head First Design Patterns, expliquant que c'est normal de souffrir un peu de « patternite » au début de l'apprentissage: 

• Le développeur débutant voit les occasions de mettre un pattern partout: "J'ai besoin d'un pattern pour Bonjour Monde"

• Le développeur intermédiaire peut distinguer où certains patterns ne sont pas applicables, mais il essaie toujours d'en utiliser trop pour les besoins.

• Le développeur gourou n'est pas obsédé par l'application de patterns. Il va les appliquer où ils sont les mieux placés. 

Un pattern est une solution à un problème récurrent. Un défi pour les débutants est d'avoir assez d'expérience pour savoir qu'un problème est récurrent. 

Très peu de problèmes résolus par les patterns GoF sont simples. C'est normal donc que la solution ne soit pas simple.

Puisque toute complexité peut nuire à un projet logiciel, il faut faire attention avant d'appliquer un design pattern: 

• • On devrait être sûr que le problème que le patron est censé résoudre existe réellement avant de tenter de l'appliquer, au moins dans un projet qui est sérieux.

  • L'application de certains patterns induit l'application d'autres patterns (p.ex. l'utilisation d'une série d'adaptateurs nécessite probablement une fabrique d'adaptateurs). Cette tendance peut ajouter de la complexité très vite.

  • Les exigences (supplémentaires) du logiciel documentent-elles le besoin de supporter l'extensibilité du logiciel favorisée par le pattern? (p.ex., y a-t-il un besoin documenté justifiant l'utilisation d'une série d'adaptateurs?)

Très peu de projets ont un objectif principal de créer un "framework" de patterns. Alors, il vaut mieux se concentrer sur la livraison d'un logiciel qui répond aux besoins pour la fonctionnalité. Les frameworks se développent naturellement à travers plusieurs itérations voire plusieurs projets. 

Finalement, il ne faut pas oublier le principe KISS. C'est une solution humble qui peut comporter moins de risque, surtout si un développeur a moins d'expérience. La simplicité est élégante et on devrait en être fier.