Pourquoi les modèles de conception ne sont-ils pas ajoutés aux constructions de langues?

Récemment, je parlais avec un collègue qui a mentionné que son entreprise travaillait sur l'ajout du modèle de conception MVC en tant qu'extension PHP.

Il a expliqué qu'ils ont écrit du code C pour l'ajouter Controllers, Models and Viewsaux constructions de langage afin d'augmenter les performances.

Maintenant, je sais que MVC est un modèle de conception architecturale qui est largement utilisé dans les applications Web, mais je dois encore rencontrer des langages qui ont une construction de langage pour les contrôleurs par exemple.

À mon humble avis, l'intégration de modèles de conception dans une langue peut souligner l'importance d'une bonne conception OO.

Alors, pourquoi les modèles de conception les plus utilisés (MVC, Factory, Strategy, ... etc.) Ne sont-ils pas ajoutés aux constructions de langage?

Si la question semble trop large, vous pouvez limiter la question à PHP uniquement.

Éditer:

Je n'implique pas que l'on doit utiliser un modèle de conception lors du développement d'un projet. En fait, je fais la promotion de la méthodologie pour rester simple aussi longtemps que cela fonctionne.

Les modèles de conception sont constamment ajoutés aux constructions de langage. Avez-vous déjà entendu parler du modèle de conception d' appel de sous- routine? Non? Moi non plus. C'est parce que les appels de sous-programme, qui étaient un modèle de conception au début des années 1950, ont été ajoutés aux langues presque instantanément. De nos jours, ils sont même présents dans les jeux d'instructions de code machine des CPU.

Qu'en est-il du modèle de conception For Loop ? Le modèle de conception de boucle While ? Le modèle de conception de commutateur ? Le modèle de conception d' objet ? Le modèle de conception de classe ? Tous ces éléments ont été ajoutés à certaines langues.

Certains d'entre eux sont. Par exemple, les itérateurs sont des fonctionnalités linguistiques dans de nombreuses langues et leurs bibliothèques standard (salut, foreach et yield return). Observer est également fréquemment présent sous forme d'événements (pas en PHP - vous devez gérer vous-même l'abonnement de rappel). La commande est une fonctionnalité essentielle de WPF.

Beaucoup d'autres ne bénéficieraient pas vraiment du support de la langue (et rendraient la langue plus lourde) - comment simplifieriez-vous les contrôleurs si vous pouviez concevoir une fonctionnalité de langue pour eux? En tant que classes, ils bénéficient de toute l'infrastructure déjà présente pour prendre en charge les classes - vous pouvez les instancier, les faire circuler et par exemple les tester unitairement comme tout autre objet.

Le seul composant de MVC dont IMO pourrait bénéficier d'une sorte de prise en charge linguistique est View (avec un moteur de modèle officiel) - et il est déjà en quelque sorte pris en charge en PHP - vous pouvez créer et charger dynamiquement des scripts PHP (qui sont souvent avec une sorte de prétraitement utilisé comme modèle).

La même chose s'applique à la méthode d'usine - comment simplifieriez-vous cela, si vous pouviez avoir n'importe quel type de fonctionnalité de langue que vous vouliez? Une fonctionnalité qui manque à certains langages (comme C ++) est la capacité de construire un objet à partir de ce nom de type, mais la plupart des langages de niveau supérieur peuvent le faire (et il n'est même pas nécessaire de créer des méthodes d'usine utiles). En dehors de cela, tout ce dont vous avez besoin est de pouvoir créer une méthode qui instancie et retourne et objecte.

Certains modèles de conception sont en effet ajoutés en tant que constructions de langage - ils ne sont tout simplement pas identifiés comme tels parce que les gens commencent à les considérer comme une "syntaxe" une fois qu'ils sont intégrés. La gestion des exceptions en Java est un bon exemple - beaucoup de gens coderaient quelque chose de similaire explicitement comme modèle de conception s'il ne faisait pas partie de la syntaxe principale.

Mais pour se concentrer sur la question - il existe de nombreuses raisons pour lesquelles vous ne voudriez pas ajouter trop de modèles de conception à une langue:

• Il n'est pas nécessaire de les ajouter en tant que constructions de langage - tous les modèles de conception peuvent être implémentés d'autres manières
• Cela compliquerait la langue - c'est une mauvaise idée car elle rend la langue plus difficile à apprendre, rend les compilateurs et les outils plus difficiles à écrire
• Des approches de mise en œuvre alternatives existent pour de nombreux modèles de conception. Choisir une approche et la bénir dans le langage de base amènerait probablement les gens à utiliser cette approche par rapport aux autres (ce qui pourrait être bien mieux dans certaines circonstances)
• Une confiance excessive dans les modèles de conception est probablement une mauvaise idée dans tous les cas - les concepteurs de langage se rendent probablement compte qu'ils ne devraient pas les encourager encore plus.

De plus, si vous utilisez un langage suffisamment puissant avec des capacités de métaprogrammation (par exemple un Lisp), il devient relativement simple d'étendre le langage vous-même pour implémenter n'importe quel modèle de conception. Vous n'avez pas besoin de modèles du tout dans le langage de base s'il est facile d'ajouter le vôtre avec une macro à 5 lignes.

Pourquoi les modèles de conception les plus utilisés (MVC, Factory, Strategy, ... etc.) Ne sont-ils pas ajoutés aux constructions de langage?

La plupart de ces modèles peuvent être implémentés dans la plupart des langages de programmation sans prise en charge linguistique spécifique. Prenez par exemple MVC en Java:

• Vous pouvez le coder directement.
• Vous pouvez l'implémenter à l'aide d'un générateur d'application ... et prendre soin d'un tas d'autres passe-partout en même temps.
• Vous pouvez l'implémenter en utilisant des classes de bibliothèque "framework".
• Vous pouvez l'implémenter à l'aide d'annotations et de traitement d'annotations statiques ou d'exécution.

Compte tenu de toutes ces options, il est peu utile d'étendre directement la langue. Et il y a plusieurs "inconvénients":

• Cela aurait tendance à encombrer la syntaxe du langage, ce qui (sans doute) rend la vie plus difficile aux programmeurs débutants.
• Cela aurait tendance à rendre la spécification du langage plus grande et plus complexe, ce qui rendrait les implémenteurs de langage plus difficiles. (Et, bien sûr, plus la spécification est grande, plus il y aura des erreurs et des incohérences.)
• Il y aura toujours de la pression pour ajouter un autre modèle ... conduisant à des problèmes / préoccupations avec la stabilité de la langue.
• En prenant en charge des modèles spécifiques dans la langue, vous câblez des façons spécifiques de prendre en charge les modèles, qui peuvent ne pas convenir à certaines applications.

Elles sont.

Les fonctions étaient un modèle de conception dans le code d'assemblage avant de devenir une construction de langage en C.

Les fonctions virtuelles étaient un modèle de conception en C avant de devenir une construction langiage en C ++.

Cependant, il y a un compromis. Si le modèle implique la production de code passe-partout (même quelques mots-clés), c'est une indication que ce serait une fonctionnalité de langue utile. Mais si le modèle est simple et clair, par exemple. C "pour (int i = 0; i <10; i ++)", il est toujours utile pour tout le monde de l'écrire de la même manière, mais ce n'est pas beaucoup plus long que "pour i = 0 à 10" et a l'avantage significatif qu'il est évident comment le modifier pour faire une boucle légèrement différente.

Lisez le livre «gang des quatre» et il deviendra clair que:

1. Les modèles de conception dans le livre sont en fait des conventions smalltalk bien connues encodées dans d'autres langages OO.
2. En tant que tels, ces modèles ne peuvent pas être inclus dans le langage OO - il s'agirait de réimplémenter smalltalk à l'intérieur de ces langages - il est préférable d'utiliser smalltalk directement
3. La raison pour laquelle les modèles de conception sont utiles est qu'ils mettent moins l'accent sur le rôle du langage actuellement utilisé et se concentrent sur d'autres questions que la syntaxe. L'encodage de ces modèles à l'intérieur de la langue perdrait cette caractéristique des modèles de conception.
4. Le vrai problème dans la question ci-dessus est qu'il manque le point que l'écriture de logiciels ne concerne pas seulement l'apprentissage de la langue. Il est important de prendre suffisamment de distance par rapport à la langue directement fournie et de se concentrer sur les exigences actuelles.

Parce que les modèles de conception sont parfaitement mis en œuvre avec le code utilisateur. Son exemple ne s'est produit que parce qu'il s'agit de PHP, mais si vous aviez réellement besoin de performances, vous travailleriez simplement dans un autre langage ou vous procurer HipHop ou quelque chose.

Les fonctionnalités du langage sont compliquées, à la fois pour spécifier et pour implémenter, et il n'est pas justifiable d'en créer un dans le seul but de "Les idiomes actuels sont X". Vous enregistrez à peine n'importe quel code utilisateur significatif, et pour rien.

Eh, question obsolète mais je suis en désaccord avec beaucoup de réponses selon l'endroit où vous définissez "Design Patterns" sur le cadran sémantique, y compris celui accepté.

Dans le sens du livre GoF Design Patterns, je dirais que cela dépend. MVC, par exemple (pas vraiment un modèle GoF mais qui correspond à ce moule), est totalement inapproprié à exprimer en tant que constructions de langage pour la consommation de masse (bien que cela puisse avoir un sens pour un projet PHP spécifique). En tant que modèle architectural, il existe des variations constantes sur le thème et une grande variété d'interprétations parfaitement légitimes sur celui-ci pour différentes circonstances (bien que beaucoup s'écartent si loin de MVC, ils ne devraient probablement plus l'appeler MVC). Par exemple, sur le Web, la barrière http en fait un ajustement quelque peu gênant selon que vous essayez d'inclure le côté client (sans doute douloureusement) dans l'équation et ce que vous envisagez "la vue" d'un point de vue plus perspective strictement strictement côté serveur.

Iterator, d'autre part, est un concept très général qui peut être appliqué de très nombreuses façons à une grande variété de constructions.

Où la ligne doit être tracée pour savoir si quelque chose appartient à une conception de langage de base, même dans une langue spécifique au Web côté serveur, IMO, est le point où quelque chose franchit la ligne de rendre plus facile de faire un nombre incalculable de choses plus facilement vs faire une chose trop spécifique mais largement mise en œuvre comme un modèle d'architecture pour vous.