Les modèles de conception sont des outils. Comme les outils, il y a deux manières de les utiliser: la bonne et la mauvaise. Par exemple, si je vous donne un tournevis et un clou et vous demande de joindre deux morceaux de bois, vous devriez me demander un marteau. Les marteaux sont utilisés pour les clous, tandis que les tournevis sont utilisés pour les vis.
Trop souvent, un modèle de conception est présenté comme la seule façon, ce qui n’est souvent vrai que lorsque des problèmes particuliers se posent. Les développeurs juniors sont souvent comme des enfants lorsqu'ils trouvent quelque chose de nouveau avec lequel jouer. ils veulent appliquer ce modèle à tout . Et il n’ya rien de mal en soi, du moment qu’ils apprennent que le motif A s’applique au problème B et que le motif C s’applique au problème D. De même que vous n’utilisez pas de tournevis pour enfoncer des clous, vous motif juste parce qu'il existe; vous utilisez le motif parce que c'est le meilleur outil (connu) pour le travail.
Le revers des modèles est anti-modèles. Des choses qui se sont maintes fois avérées mauvaises, généralement en termes de temps d'exécution ou de mémoire. Cependant, les modèles et les anti-modèles ne sont pas bénéfiques pour le développeur qui ne comprend pas pourquoi ils existent. Les développeurs aiment penser que ce qu'ils font est nouveau et inventif, mais la plupart du temps, ils ne le sont pas. Il a probablement été pensé avant. Les personnes qui les ont précédés ont créé les modèles en raison de leur expérience.
Bien sûr, les développeurs débutants semblent souvent proposer de nouvelles façons de faire les choses anciennes, et parfois ces méthodes sont meilleures. Cependant, trop souvent, il s’agit de l’effet Dunning-Kruger; le développeur en sait juste assez pour créer un programme fonctionnel, mais ne comprend pas ses propres limites. La seule façon de surmonter ce problème semble être l’expérience, tant positive que négative. Ils ignorent les modèles parce qu'ils se croient supérieurs, mais ne savent pas qu'en réalité, 10 000 développeurs ont déjà utilisé un modèle spécifique, puis l'ont abandonné car il était mauvais.
Agile préfère "faire avancer les choses" en ce qui concerne son adaptation rapide à l'évolution des besoins des clients. Il ne favorise pas les modèles de conception, ni ne les méprise. Si un motif est la méthode la plus rapide et la plus fiable, le développeur doit l’utiliser. Si un modèle particulier coûte plus de temps que simplement "le faire", il est probablement correct d'utiliser quelque chose qui n'est pas un modèle (en supposant, bien entendu, que les performances ne sont pas gravement dégradées, etc.). Si aucun motif connu ne peut être trouvé, il est préférable de concevoir leur propre motif plutôt que de dire «non» à un client. Les clients, en particulier les clients payants, ont généralement raison.
Quiconque prétend que les modèles sont la voie, ou prétend que les modèles sont le fléau de l'existence, ont tort. Les modèles sont des outils destinés à être appliqués à des situations spécifiques et ont des degrés de réussite variables en fonction des circonstances. C’est une vérité, qui ne dépend pas de savoir si vous avez choisi MVC ou non, si vous utilisez des objets de transfert de données, etc. et est raisonnablement exempt de bugs logiques.
Habituellement , les motifs permettent une forme cohérente de conception et donnent de meilleurs résultats que d'ignorer tous les motifs au lieu d'écrire des idées 100% originales, mais vous ne pouvez pas éviter tous les motifs. Par exemple, si y = x + 5, allez-vous vraiment écrire y = x + (5 * 3 + 15/3) / 4, juste pour éviter le motif d'écriture x + 5? Non, vous n'êtes pas. Vous allez écrire y = x + 5 et passer au problème suivant.
Les gens utilisent des modèles tous les jours, et ce n'est pas grave . Ce qui compte le plus, c’est d’avoir un code qui fonctionne logiquement, qui plante et qui est facile à utiliser. Rien d'autre ne compte plus que cela.