Les modèles de conception sont-ils vraiment essentiels de nos jours?
Je lisais "Coders at Work" et j'ai fait face au fait que certains des professionnels interrogés dans le livre ne sont pas aussi enthousiastes à propos des modèles de conception.
Je pense qu'il y a 2 raisons principales à cela:
Les modèles de conception nous obligent à penser en leurs termes. En d'autres termes, il est presque impossible d'inventer quelque chose de nouveau (peut-être mieux).
Les modèles de conception ne durent pas éternellement. Les langues et les technologies changent rapidement; par conséquent, les modèles de conception deviendront finalement non pertinents.
Il est donc peut-être plus important d'apprendre à programmer correctement sans schémas particuliers et de ne pas les apprendre.
Le fait était également que, généralement, lorsque les gens sont confrontés à un problème et qu'ils 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. Quand il est temps de changer 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 profondément.
Pour mon argent, je pense que tout le monde manque le point de modèles de conception. Il est rare que je m'assoie en me demandant quel modèle je dois utiliser dans une situation donnée. De plus, j'utilisais la plupart de ces modèles bien avant de savoir qu'ils avaient des noms.
La puissance des modèles de conception réside dans la communication. Il m'est beaucoup plus rapide de dire "utilisez une stratégie pour cela" que de décrire en détail ce que je propose. Il est beaucoup plus facile pour nous de débattre des avantages des modèles de domaine volumineux par rapport aux scripts de transaction si nous savons tous ce que signifient ces deux termes. 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 lorsque je dis "Le modèle d'observateur est idéal pour cela", vous pourrez facilement le parcourir et le rechercher sur Google.
En ce sens, la puissance des modèles de conception ne se fanera jamais.
Les modèles ont deux objectifs principaux:
Résoudre les tensions de manière prévisible: Les modèles sont conçus pour résoudre un certain ensemble de tensions d'une manière connue pour fonctionner. Kent Beck, auteur de Smalltalk Best Practice Patterns , décrit les modèles 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 font souvent), les schémas qui les résolvent resteront utiles.
Multiplicateur de force de communication: Les motifs nous permettent de dire beaucoup avec un peu. Ils s'appuient sur un petit ensemble de concepts puissants et bien compris qui sont applicables dans une grande variété d'espaces problématiques. La réponse de @ pdr est morte sur la valeur communicative des modèles.
Je pense que l'affirmation selon laquelle les modèles de conception entravent l'innovation est complètement fausse. Vous devez savoir où existe déjà afin de ne pas avoir à réinventer la roue. Pour être temporaires, les modèles dans leur ensemble s'appliquent aux systèmes OOP et ne sont liés à aucune plate-forme ou langue particulière.
Maintenant, ce que je n'aime pas quand les gens parlent de modèles, c'est que certaines personnes ont une sorte d'obsession pour eux. J'ai eu un jour un client qui me demandait "d'inclure au moins deux modèles supplémentaires" (WTF?!) Car en raison du manque de mots à la mode dans mon code, il ne semblait pas assez entreprenant.
Peut-être que le concept de anti-motifs est pertinent. Je ne pense pas que l'étude des modèles de conception soit l'étape critique pour devenir ingénieur logiciel. La conception de logiciels est importante, souvent réservée comme la prérogative de l'architecte logiciel sur un projet, mais en réalité quelque chose qui peut être martelé par consensus dans l'équipe proverbiale "bien gélifiée".
Mais les modèles de conception et les anti-modèles constituent une ressource pour ces discussions. Il faut apprécier les leçons des choses qui ont bien fonctionné (ou pas) et comment tirer parti (ou atténuer) les conséquences des choix de conception. Une bonne équipe pourrait trouver son propre vocabulaire pour de telles discussions, mais ce n'est vraiment pas une si mauvaise chose de référencer les normes de facto élaborées par des auteurs qui 'ai été là, fait ça.
Il existe deux types de modèles de conception:
- niversal patterns, qui sont beaucoup plus sur la façon d'organiser des programmes complexes afin que vous puissiez les comprendre. Ceux-ci ne disparaissent pas, bien que d'autres exemples puissent être découverts.
- Modèles 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 deviennent inutiles.
D'accord, tous les modèles sont sans doute quelque peu situationnels, mais pour certains, les forces proviennent du monde réel et pour d'autres, les forces proviennent 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. Personne 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 s'est passé auparavant. Pensez-vous que Rieman n'a jamais lu Euclide?
Les modèles de conception présentent des avantages lorsqu'ils réduisent le temps que vos collègues ou vos clients passent à penser "Comment cela fonctionne-t-il?". Même s'il n'y a aucun sens à appliquer une norme pour la normalisation, s'il existe une façon courante et bien comprise de faire quelque chose, chaque fois qu'un codeur recherche ce modèle en espérant le trouver et le fait, vous avez fait son travail et vos travaux Plus facile.
Je crois que le gang de quatre eux-mêmes classent les modèles de conception comme
une solution commune à un problème courant *
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 produit à plusieurs reprises. Donc, en réalité, il n'y a pas de modèle de conception, il y a un modèle de problèmes.
Certains langages de programmation peuvent avoir des solutions natives à certains de ces problèmes. Le livre "Design Patterns" mentionne lui-même que le modèle de visiteur est de peu de valeur si vous utilisez CLOS, car le multi-dispatch est pris en charge nativement par CLOS, le problème même que le modèle de visiteur essaie de résoudre.
En outre, le framework .NET dispose d'un mécanisme d'événement intégré pour publier des événements sur plusieurs écouteurs, ce qui rend le modèle Observer moins pertinent dans ce contexte.
Le passage des applications de bureau aux applications Web ** change également le type de problèmes de programmation que nous devons résoudre. De nombreux modèles du livre "Design Patterns" sont pertinents pour les applications de bureau, mais pas tant pour les applications Web. Bien sûr, avec des applications à page unique, ces modèles peuvent être à nouveau pertinents du côté client.
Mais les modèles de conception et les livres comme "Design Patterns" ou "Patterns of Enterprise Application Architecture" sont d'une grande valeur lorsque vous êtes un programmeur débutant et confronté à un nouveau type de problème pour la première fois; car c'était la première fois qu'on m'a demandé d'implémenter la fonctionnalité Annuler. Sans le livre "Design Patterns", mon implémentation aurait probablement consisté à stocker un instantané des données après chaque opération de changement d'état *** - une approche très sujette aux erreurs et horriblement inefficace.
Alors oui, certains modèles deviennent moins pertinents au fil du temps, et lorsque vous devenez un programmeur expérimenté, vous y pensez moins. Mais pour un novice, elles sont précieuses, tant que vous vous souvenez qu'elles sont le moyen de résoudre un problème - et non une quête pour en utiliser le plus possible.
* le devis peut ne pas être précis à 100% car il est extrait de la mémoire
** d'après mon expérience, il est de plus en plus courant pour les entreprises de choisir des mécanismes de diffusion Web pour les applications internes au secteur d'activité.
*** après avoir appris la programmation fonctionnelle et les structures de données fonctionnelles, cela pourrait être la façon dont je le résoudrais aujourd'hui.