Les design patterns sont-ils vraiment des faiblesses du langage ?

Question

Les modèles d'aujourd'hui devraient-ils être considérés comme des défauts ou des fonctionnalités manquantes en Java et C++. ?

• Sous-programme était un modèle de conception pour le langage machine dans les années 50 et 60.
• Classe orientée objet était un modèle de conception pour le C dans les années 70.

• Visiteurs, usines abstraites, décorateurs et façades sont des modèles de conception pour Java et C++ aujourd'hui.

  À quoi ressembleront les langues de demain ? Quels modèles ils ont ?

Answer 1

Certains modèles de conception canonisés - Adapter, Factory, Command, Visitor, etc. - sont des approximations de fonctionnalités intégrées à d'autres langages. En tête de liste :

• Les gestionnaires d'événements en C# sont des versions intégrées du modèle de l'observateur. Pensez à la façon dont vous câbleriez les événements en C# si vous deviez lancer votre propre observateur à chaque fois.

• Le modèle de visiteur est une approximation verbeuse de multiméthodes , transfert de messages ou une forme très faible de filtrage par motif .

• Le motif de commande enveloppe un comportement particulier afin que vous puissiez passer l'objet entre les méthodes, ce qui se rapproche plus ou moins des fonctions de première classe.

• Le modèle de stratégie vous permet d'insérer dynamiquement un comportement dans un objet, de sorte qu'à tout moment, vous pouvez modifier l'objet en remplaçant un comportement par un autre. Dans le monde de la programmation fonctionnelle, on appelle cela la composition de fonctions.

• Le modèle de fabrique abstraite accepte un argument et renvoie une fabrique comme résultat. En général, vous pouvez considérer les fabriques comme des enveloppes autour d'une fonction (plus spécifiquement, des enveloppes autour d'un constructeur). Ainsi, vous passez des arguments à une fonction et obtenez une fonction en tant que résultat, ce qui rend ce modèle assez analogue au curry.

• Le modèle du décorateur permet d'attacher ou de supprimer des comportements à un objet au moment de l'exécution. En JavaScript, vous pouvez ajouter ou supprimer des fonctions sans implémenter explicitement le modèle décorateur grâce au modèle OO "prototype".

Ainsi, nous avons un tas de patrons de conception qui émulent des caractéristiques intrinsèques à d'autres langages. L'envie de fonctionnalités n'indique pas nécessairement une faiblesse dans le langage - c'est le code standard que vous devez écrire. encore et encore et encore qui indique la faiblesse de la langue.

Answer 2

Je ne les appellerais pas des défauts.

Les langues d'ordre supérieur traitent des concepts à un niveau plus élevé que les langues d'ordre inférieur. Pensez-y en termes de construction.

Vous pourriez construire un bâtiment au niveau de la raffinerie, fraiser du bois, fondre de l'acier, et assembler un bâtiment de cette façon.

Vous pouvez acheter des planches et des poutres en acier, et les construire pour en faire un bâtiment.

Vous pouvez acheter des murs et des fermes préfabriqués et les construire en un bâtiment.

Vous pouvez acheter un bâtiment et commencer par l'intérieur.

Construire un bâtiment avec des planches et des poutrelles, c'est manquer la caractéristique du mur préfabriqué, ou être défectueux d'une manière ou d'une autre ?

Answer 3

Chaque chose que vous faites trois fois ou plus dans les conceptions de logiciels forme un modèle.

Chaque répétition. Chaque répétition. Chaque répétition.

Certains sont canonisés avec des noms cool. Ceux-ci deviennent des Design Patterns. Répétition consciente.

Certains ne sont que des "meilleures pratiques" ou "cela a marché pour moi". Ce sont des modèles de conception sans la clarté.

Certaines sont juste des "choses que vous faites habituellement". Il s'agit de modèles de conception sans que l'on reconnaisse consciemment que l'on se répète.

Les modèles de conception ont rien à la faiblesse ou à l'incomplétude de la langue. Ils ont tout à faire avec les bonnes idées, consciemment réutilisées.

Les patrons de conception d'aujourd'hui ne sont pas la voie royale vers les langages de demain. Le paradigme des langages ne progresse pas par une série de "corrections de bugs des langages précédents". Si c'était le cas, nous n'aurions jamais créé Visual Basic.

Et les modèles de conception constituent un outil intellectuel bien plus vaste et plus large qu'un simple ensemble de fonctionnalités d'un langage de programmation.

Answer 4

Non, il ne s'agit pas de fonctionnalités manquantes ou de défauts des langues. Mais les langages devraient fournir un moyen d'écrire le code d'un modèle utile. plus facile plutôt que difficile. C'est là que les fonctions qui sont fournie par la langue peut être soit une aubaine, soit un obstacle.

Answer 5

Je pense qu'Ewan soulève un point fascinant. Prenons l'exemple de sa " sous-routine ". Dans les premiers langages de programmation, l'idée de passer des paramètres à une sous-routine et de retourner un résultat était quelque chose que vous deviez coder explicitement. Dans les langages modernes, c'est intégré. Ou pour prendre un autre exemple : If/then/else est intégré dans la plupart des langages modernes, sinon tous. Mais à l'époque où j'étais assembleur, je devais écrire du code pour accomplir cela. Pas beaucoup, bien sûr, mais quand même, il fallait écrire l'instruction jump ou goto pour contourner le bloc else. Et le fait que vous deviez écrire ces choses vous-même signifiait que différents programmeurs le feraient de manière légèrement différente, et il y avait la tentation sans fin d'être intelligent et de le faire un peu différemment dans ce programme pour le rendre plus efficace ou obtenir un autre avantage supposé.

L'exemple le plus récent qui me vient à l'esprit est celui des itérateurs. Vous devez les écrire à la main en C++ et dans les premières versions de Java, mais ils sont intégrés à Java 5. On peut dire qu'il s'agit d'un sucre syntaxique, car il est tout aussi bien de créer simplement des fonctions d'itérateurs. Personnellement, je pense que c'est une fonctionnalité intéressante. Est-ce que cela améliore radicalement ma productivité ? Non.

Y a-t-il quelque chose que nous faisons tout le temps et qui devrait logiquement être intégré au langage pour le normaliser et le simplifier ? C'est une question fascinante. Je ne pense pas que quiconque puisse sérieusement prétendre que même son langage préféré est parfait et qu'aucune amélioration n'est possible. Mais quelle sera l'orientation du prochain langage ?

Il est certain que certaines fonctionnalités qui ont été ajoutées aux langages sont des bagages supplémentaires inutiles. À mon humble avis, les enum de Java font beaucoup plus que ce qui est nécessaire, ils ajoutent un tas de bagages sans raison valable. Je suis sûr que d'autres ne seront pas d'accord et diront qu'ils les trouvent incroyablement utiles.

Je n'ai pas de conclusion. Je reconnais simplement que c'est une question fascinante.