Les modèles de conception sont-ils vraiment essentiels de nos jours?

Je lisais "Coders at Work" et j'ai constaté que certains des professionnels interrogés dans le livre n'étaient pas aussi enthousiastes à propos des modèles de conception.

Je pense qu'il y a 2 raisons principales à cela:

1. Les modèles de conception nous obligent à penser selon leurs termes. En d'autres termes, il est presque impossible d'inventer quelque chose de nouveau (peut-être mieux).

2. Les modèles de conception ne durent pas éternellement. Les langues et les technologies changent rapidement. par conséquent, les modèles de conception finiront par devenir inutiles.

Il est donc peut-être plus important d'apprendre à programmer correctement sans utiliser de modèles particuliers et de ne pas les apprendre.

Le fait était aussi que, généralement, lorsque les gens font face à un problème et n’ont pas beaucoup de temps, ils essaient d’utiliser un modèle. Cela signifie copier et coller du code existant dans votre projet avec des modifications mineures afin de le faire fonctionner. Lorsqu'il est temps de modifier ou d'ajouter quelque chose, un développeur ne sait pas par où commencer car ce n'est pas son code et il ne le connaît pas bien.

Pour mon argent, je pense que tout le monde manque le but des modèles de conception. Il est rare que je me demande quel schéma je devrais utiliser dans une situation donnée. En outre, j'utilisais la plupart de ces modèles bien avant que je sache qu'ils avaient des noms.

Le pouvoir des modèles de conception est en communication. Il est beaucoup plus rapide pour moi de dire "utiliser une stratégie pour cela" que de décrire en détail ce que je suggère. Il est beaucoup plus facile pour nous de débattre des avantages des modèles de domaine gras par rapport aux scripts de transaction si nous savons tous ce que ces deux termes signifient. Etc.

Et le plus puissant de tous, si j'ai nommé une classe FooBuilder, alors vous savez que j'utilise le modèle Builder pour générer mon Foo.

Même si vous ne savez pas de quoi je parle quand je dis "Le modèle Observer est idéal pour cela", vous pourrez partir et google assez facilement.

En ce sens, le pouvoir des modèles de conception ne faiblira jamais.

Les modèles ont deux objectifs principaux:

• Résoudre les tensions de manière prévisible : les schémas sont conçus pour résoudre un certain ensemble de tensions de manière connue. Kent Beck, auteur de Smalltalk Best Practice Patterns , décrit les motifs comme un moyen de répéter la décision qu'un expert prendrait dans des circonstances similaires. Tant que les tensions restent les mêmes (et elles le sont souvent), les schémas qui les résolvent resteront utiles.

• Multiplicateur de force de communication : Les schémas nous permettent de dire beaucoup avec un peu. Ils s'appuient sur un petit ensemble de concepts puissants et bien compris, applicables dans une grande variété d'espaces problématiques. La réponse de @ pdr est sans fondement sur la valeur communicative des modèles.

Je pense que l'affirmation selon laquelle les modèles de conception empêchent l'innovation est complètement fausse. Vous devez savoir où existe déjà pour ne pas avoir à réinventer la roue. Pour être temporaires, les modèles dans leur ensemble s’appliquent aux systèmes POO et ne sont pas liés à une plate-forme ou à un langage particulier.

Ce que je n'aime pas quand on parle de modèles, c'est que certaines personnes en sont obsédées. Un jour, un client m'a demandé "d'inclure au moins deux autres motifs" (WTF ?!) car, en raison du manque de mots à la mode dans mon code, cela ne semblait pas être une entreprise assez.

Peut-être que le concept d' anti-patterns est pertinent. Je ne pense pas que l’étude des modèles de conception soit l’étape critique pour devenir un ingénieur en logiciel. La conception logicielle est importante, elle est souvent réservée à l’architecte logiciel sur un projet, mais c’est réaliste mais elle peut être élaborée par consensus au sein de l’équipe "bien gélifiée".

Mais les modèles de conception et les anti-modèles constituent une ressource pour ces discussions. Il faut comprendre les leçons de choses qui ont bien fonctionné (ou pas) et savoir comment capitaliser (ou atténuer) les conséquences des choix de conception. Une bonne équipe pourrait avoir son propre vocabulaire pour de telles discussions, mais ce n’est vraiment pas une si mauvaise chose de faire référence aux normes de facto élaborées par les auteurs qui y sont déjà allés.

Il existe deux types de modèles de conception:

1. Les modèles universels , qui traitent beaucoup plus de la manière d’organiser des programmes complexes afin que vous puissiez les comprendre. Ceux-ci ne vont pas disparaître, même si d'autres exemples peuvent être découverts.
2. Les schémas situationnels , qui sont tellement liés aux forces particulières induites par les contraintes (par exemple, le langage de programmation), que lorsque ces forces changent, elles perdent leur pertinence.

OK, on ​​peut soutenir que tous les modèles sont un peu situationnels, mais avec certains les forces viennent du monde réel et avec d’autres les forces viennent des outils. Les outils changent beaucoup plus rapidement que le monde réel.

Lire sur les modèles de conception, c'est comme apprendre les mathématiques au lieu de les réinventer. Rien ne vous empêche de faire de grands progrès dans un certain domaine une fois que vous avez une solide compréhension de ce qui se passait auparavant. Pensez-vous que Rieman n'a jamais lu Euclid?

Les modèles de conception présentent un avantage lorsqu'ils permettent de réduire le temps que vos collègues ou clients consacrent à la réflexion "Comment ça marche?". Même s'il est inutile d'appliquer une norme à des fins de normalisation, s'il existe une manière commune et bien comprise de faire quelque chose, chaque fois qu'un codeur recherche ce modèle qui l'attend et le fait, vous avez créé son travail Plus facile.

Je crois que la bande des quatre classe elle-même les modèles de conception

une solution commune à un problème commun *

Alors oui, les modèles sont pertinents lorsque le même type de problème se produit. Et cela nous amène à un problème avec le terme "Design Pattern". Un motif est quelque chose de reconnaissable qui se répète. Donc, en réalité, il n'y a pas de modèle de conception, il y a un modèle de problème.

Certains langages de programmation peuvent avoir des solutions natives à certains de ces problèmes. Le livre "Design Patterns" indique lui-même que le motif visiteur a peu d’importance si vous utilisez CLOS, car la multi-répartition est supportée de manière native par CLOS, le problème même que le motif Visiteur tente de résoudre.

En outre, le framework .NET a un mécanisme d’événement intégré pour la publication des événements vers plusieurs écouteurs, ce qui rend le modèle Observer moins pertinent dans ce contexte.

Le passage des applications de bureau aux applications Web ** modifie également le type de problèmes de programmation que nous devons résoudre. La plupart des modèles du livre "Design Patterns" sont pertinents pour les applications de bureau, mais pas tellement pour les applications Web. Bien entendu, avec les applications à page unique, ces modèles peuvent être à nouveau pertinents du côté client.

Mais les modèles de conception, et des livres tels que «Modèles de conception» ou «Modèles d’architecture d’applications d’entreprise» ont une grande valeur lorsque vous êtes programmeur débutant et que vous faites face à un nouveau type de problème pour la première fois; comme j'étais la première fois, on m'a demandé d'implémenter la fonctionnalité d'annulation. N'eût été le livre "Design Patterns", mon implémentation aurait probablement été quelque chose comme stocker une capture instantanée des données après chaque opération de changement d'état *** - une approche très sujette aux erreurs et horriblement inefficace.

Donc, effectivement, certains modèles deviennent moins pertinents au fil du temps et, à mesure que vous devenez un programmeur expérimenté, vous y réfléchissez moins. Mais pour un novice, ils sont précieux, pour autant que vous vous rappeliez qu’ils sont le moyen de résoudre un problème - et non une quête pour en utiliser le plus possible.

* devis peut ne pas être précis à 100% car il est pris de la mémoire

** D'après mon expérience, il est devenu très courant pour les entreprises de choisir des mécanismes de diffusion Web pour les applications métier internes.

*** après avoir appris la programmation fonctionnelle et les structures de données fonctionnelles, ce serait peut-être la façon dont je le résoudrais aujourd'hui.

Le respect slave des modèles de conception peut être préjudiciable - les modèles sont des solutions documentées aux problèmes courants, mais ce ne sont pas des manuels d’instructions. Cependant, ce n’est pas parce qu’ils sont discutés en détail et, dans certains cas, appliqués en dehors des domaines problématiques effectifs, qu’ils n’ont aucune valeur. Ils constituent un ensemble de principes - appelez cela un cadre - sur lesquels s’appuyer pour concevoir l’architecture d’un programme, permettant ainsi à l’architecte de donner une idée de la manière dont il / elle aimerait voir la solution fonctionner. Une bonne équipe de développement les considère comme une base de fonctionnalité plutôt que comme une spécification fonctionnelle.