Donc, «Les modèles de conception manquent-ils de fonctionnalités linguistiques»? [fermé]

J'ai vu, ici sur les programmeurs, la réponse à cette question: comment la réflexion sur les modèles de conception et les pratiques de POO change-t-elle dans les langages dynamiques et faiblement typés? Là, j'ai trouvé un lien vers un article avec un titre franc: les motifs de conception manquent-ils de fonctionnalités linguistiques . Mais là où j'ai trouvé des extraits qui me paraissaient très accrocheurs et qui peuvent probablement être vérifiés par rapport à l'expérience, il y a une incitation à cela, comme:

PaulGraham a déclaré: "Peter Norvig a constaté que 16 des 23 modèles de Design Patterns étaient" invisibles ou plus simples "en Lisp."

ou une autre phrase qui confirme ce que j'ai récemment vu avec des gens essayant de simuler des classes en JavaScript:

Bien sûr, personne ne parle jamais du modèle de "fonction" ou du modèle de "classe", ou de nombreuses autres choses que nous tenons pour acquises car la plupart des langages les fournissent en tant que fonctionnalités intégrées. OTOH, programmeurs dans un langage purement PrototypeOrientedLanguage? pourrait bien trouver pratique de simuler des classes avec des prototypes ...

Je prends également en considération que les modèles de conception sont un outil de communication . Parce que même avec mon expérience limitée dans la création d'applications, je peux voir comme un anti-modèle ( inefficace et / ou contre-productif ) par exemple, forçant une petite équipe PHP à apprendre des modèles GoF pour une application intranet petite à moyenne. Je suis conscient que l'échelle, la portée et le but peuvent déterminer ce qui est efficace et / ou productif, mais je n'ai toujours pas réussi à trouver un aperçu technique à ce sujet.

J'ai vu de petites applications commerciales qui mélangeaient les fonctionnalités avec la POO et étaient toujours maintenables, et je ne sais pas si beaucoup auraient besoin par exemple en python pour écrire un singleton, mais pour moi, un simple module fait la même chose.

Y a-t-il donc des études, des articles exhaustifs ou d'autres formes d'exposition qui prennent en considération les modèles de conception par rapport aux solutions de contournement par rapport aux moyens plus simples de le faire, ou les remplacements par des fonctionnalités linguistiques?

Je ne suis au courant d'aucune discussion ou étude approfondie qui tienne compte de toutes ces choses.

Cela dit, l'argument selon lequel "les modèles de conception ne font que corriger les fonctionnalités manquantes dans les langages OO" est un peu mince, à mon avis. Oui, certains modèles de conception sont exactement cela, ils remplissent une lacune commune qui n'existe même pas dans une autre langue X. Ce sont généralement vos modèles de conception simples et de bas niveau, comme certains / beaucoup des modèles originaux dans le livre du GoF.

Mais les modèles de conception vont bien au-delà de ces simples, et les appeler fonctionnalités linguistiques manquantes étire l'imagination. Jetez un coup d'œil au catalogue de modèles d'applications d'entreprise de Fowler et réfléchissez à ce que ce serait si ces éléments faisaient tous partie de la définition de base d'un langage. Je suppose que vous vous retrouveriez avec un langage spécifique au domaine ( DSL ) pour les applications d'entreprise (et très complexe, à ce sujet).

C'est donc la chose, vraiment - les modèles de conception sont un moyen de trouver des solutions réutilisables pour des problèmes particuliers (qui sont souvent appliqués dans un langage générique polyvalent). C'est là que la communication intervient également. Si vous me dites "nous utilisons Active Records", je connais déjà beaucoup de choses sur votre application, sans passer des minutes à discuter des différentes approches. Alors oui, les modèles de conception font des trous dans la spécification de langue. C'est tout ce qu'ils font? Non - pas de loin.

Éditer:

D'une certaine manière, ce que je dis, c'est que les modèles permettent aux praticiens OO de penser à un niveau supérieur et de presque construire un type de DSL pour leur environnement, tout en restant dans la syntaxe de leur langue. Et oui, j'ai vu ce qui se passe lorsque vous les appliquez partout (voir: AbstractSingletonProxyFactoryBean , oui, cela existe), ou pensez que ce sont des sortes de solutions miracles. Le fait est que bien qu'ils mettent beaucoup de temps à être vraiment à l'aise, ils sont censés réduire la complexité en rendant les choses prévisibles / compréhensibles à un niveau élevé. C'est très différent d'être un patch-kit pour les défauts de votre langue.

Edit 2 - a ajouté le contre-exemple AbstractSingletonProxyFactoryBean pour se moquer des modèles. Pour être tout à fait juste, vu sous une lumière AOP, même ce contre-exemple est défendable.