La functional programming remplace-t-elle les modèles de conception GoF?

Le blog que vous avez cité surestime un peu sa revendication. FP n’élimine pas le besoin de modèles de conception. Le terme “modèles de conception” n’est pas très utilisé pour décrire la même chose en langage FP. Mais ils existent. Les langages fonctionnels contiennent de nombreuses règles de bonnes pratiques de la forme “lorsque vous rencontrez le problème X, utilisez du code qui ressemble à Y”, ce qui est fondamentalement ce qu’est un modèle de conception.

Cependant, il est vrai que la plupart des modèles de conception spécifiques à la POO ne sont pas très pertinents dans les langages fonctionnels.

Je ne pense pas qu’il soit particulièrement controversé de dire que les modèles de conception en général n’existent que pour pallier les lacunes de la langue. Et si une autre langue peut résoudre le même problème sortingvialement, cette autre langue n’aura pas besoin d’un modèle de conception. Les utilisateurs de cette langue peuvent même ne pas savoir que le problème existe , car, bien, ce n’est pas un problème dans cette langue.

Voici ce que le Gang of Four a à dire sur cette question:

Le choix du langage de programmation est important car il influence le sharepoint vue. Nos modèles supposent des fonctionnalités de langage de niveau Smalltalk / C ++, et ce choix détermine ce qui peut et ne peut pas être implémenté facilement. Si nous prenions des langages procéduraux, nous aurions pu inclure des modèles de conception appelés “inheritance”, “encapsulation” et “polymorphism”. De même, certains de nos modèles sont directement pris en charge par les langages orientés object les moins courants. Le CLOS a plusieurs méthodes, par exemple, ce qui réduit la nécessité d’un modèle tel que Visitor. En fait, il existe suffisamment de différences entre Smalltalk et C ++ pour signifier que certains modèles peuvent être exprimés plus facilement dans une langue que dans l’autre. (Voir Itérateur par exemple.)

(Ce qui précède est une citation du livre Introduction to the Design Patterns, page 4, paragraphe 3)

Les principales caractéristiques de la functional programming comprennent des fonctions telles que des valeurs de première classe, le curry, des valeurs immuables, etc. Il ne me semble pas évident que les modèles de conception OO se rapprochent de ces fonctionnalités.

Quel est le modèle de commande, sinon une approximation des fonctions de première classe? 🙂 Dans un langage FP, vous devez simplement passer une fonction comme argument à une autre fonction. Dans un langage OOP, vous devez emballer la fonction dans une classe, que vous pouvez instancier, puis transmettre cet object à l’autre fonction. L’effet est le même, mais dans la POO, cela s’appelle un modèle de conception, et il faut beaucoup plus de code. Et quel est le motif de fabrique abstrait, si ce n’est le curry? Passer les parameters à une fonction un peu à la fois, pour configurer le type de valeur qu’elle crache lorsque vous l’appelez finalement.

Donc, oui, plusieurs modèles de conception GoF sont rendus superflus dans les langages FP, car des alternatives plus puissantes et plus faciles à utiliser existent.

Mais, bien sûr, il existe encore des modèles de conception qui ne sont pas résolus par les langages FP. Quel est l’équivalent FP d’un singleton? (Sans tenir compte un instant que les singletons sont généralement un modèle terrible à utiliser)

Et ça marche aussi dans les deux sens. Comme je l’ai dit, FP a aussi ses modèles de conception, les gens ne les considèrent généralement pas comme tels.

Mais vous avez peut-être rencontré des monades. Que sont-ils, sinon un modèle de conception pour “traiter avec l’état mondial”? C’est un problème si simple dans les langues de la POO qu’il n’existe aucun modèle de conception équivalent.

Nous n’avons pas besoin d’un modèle de conception pour “incrémenter une variable statique”, ou “lire depuis cette socket”, car c’est exactement ce que vous faites .

Dans les langages fonctionnels (purs), les effets secondaires et l’état mutable sont impossibles, à moins que vous ne le consortingez avec le “modèle de conception” monad, ou toute autre méthode pour autoriser la même chose.

De plus, dans les langages fonctionnels qui prennent en charge la POO (tels que F # et OCaml), il me semble évident que les programmeurs utilisant ces langages utiliseraient les mêmes modèles de conception disponibles pour toutes les autres langues de la POO. En fait, en ce moment, j’utilise F # et OCaml tous les jours, et il n’y a pas de différences frappantes entre les modèles que j’utilise dans ces langages et les modèles que j’utilise quand j’écris en Java.

Peut-être parce que vous réfléchissez toujours impérativement? Beaucoup de gens, après avoir eu affaire à des langages impératifs toute leur vie, ont du mal à abandonner cette habitude quand ils essaient un langage fonctionnel. (J’ai vu des tentatives très amusantes à F #, où littéralement chaque fonction était juste une chaîne de “let”, comme si vous aviez pris un programme C et remplacé tous les points-virgules par “let”. :))

Mais une autre possibilité pourrait être que vous ne vous êtes simplement pas rendu compte que vous résolviez des problèmes sortingvialement, ce qui nécessiterait des modèles de conception dans un langage de POO.

Lorsque vous utilisez le curry, ou transmettez une fonction comme argument à un autre, arrêtez-vous et réfléchissez à la façon dont vous le feriez dans un langage OOP.

Y a-t-il une vérité à l’affirmation que la functional programming élimine le besoin de modèles de conception de POO?

Oui. 🙂 Lorsque vous travaillez dans un langage FP, vous n’avez plus besoin des modèles de conception spécifiques à la POO. Mais vous avez toujours besoin de modèles de conception généraux, comme MVC ou d’autres éléments non spécifiques à la POO, et vous avez besoin de deux nouveaux “modèles de conception” spécifiques à FP. Toutes les langues ont leurs faiblesses et les modèles de conception sont généralement la façon dont nous les contournons.

Quoi qu’il en soit, vous trouverez peut-être intéressant de vous essayer à des langages de FP plus propres, tels que ML (mon préféré, du moins à des fins d’apprentissage), ou Haskell, où la béquille ne peut plus sont confrontés à quelque chose de nouveau.

Comme prévu, quelques personnes se sont opposées à ma définition des modèles de conception en “corrigeant les lacunes dans un langage”. Voici donc ma justification: Comme déjà dit, la plupart des modèles de conception sont spécifiques à un seul paradigme de programmation. Souvent, ils résolvent des problèmes qui n’existent que dans ce paradigme (Voir les monades pour la PF ou les usines abstraites pour la POO). Pourquoi le modèle d’usine abstrait n’existe-t-il pas dans FP? Parce que le problème qu’il essaie de résoudre n’existe pas là. Donc, si un problème existe dans les langues de la POO, qui n’existe pas dans les langages de PF, il est clair que cela est un défaut des langues de la POO. Le problème peut être résolu, mais votre langue ne le fait pas, mais nécessite un tas de code standard pour vous permettre de le contourner. Idéalement, nous aimerions que notre langage de programmation élimine comme par magie tous les problèmes. Tout problème qui existe encore est en principe un défaut de la langue. 😉

Y a-t-il une vérité à l’affirmation que la functional programming élimine le besoin de modèles de conception de POO?

La functional programming est différente de la programmation orientée object. Les modèles de conception orientés object ne s’appliquent pas à la functional programming. Au lieu de cela, vous avez des modèles de conception de functional programming.

Pour la functional programming, vous ne lirez pas les livres de modèles de conception OO, vous lirez d’autres livres sur les modèles de conception de FP.

agnostique de la langue

Pas totalement. Seul langage indépendant des langues OO. Les modèles de conception ne s’appliquent pas du tout aux langages procéduraux. Ils ont peu de sens dans un contexte de conception de firebase database relationnelle. Ils ne s’appliquent pas lors de la conception d’un tableur.

un modèle de conception de POO typique et son équivalent fonctionnel?

Ce qui précède ne devrait pas exister. C’est comme demander un code de procédure réécrit en code OO. Ummm … Si je traduis l’original Fortran (ou C) en Java, je n’ai rien fait de plus que le traduire. Si je le réécris totalement dans un paradigme OO, il ne ressemblera plus à Fortran ou C original – il sera méconnaissable.

Il n’y a pas de simple correspondance entre OO Design et Functional Design. Ce sont des façons très différentes de regarder le problème.

La functional programming (comme tous les styles de programmation) a des modèles de conception. Les bases de données relationnelles ont des modèles de conception, OO a des modèles de conception, la programmation procédurale a des modèles de conception. Tout a des modèles de conception, même l’architecture des bâtiments.

Les modèles de conception, en tant que concept, constituent un mode de construction intemporel, indépendamment de la technologie ou du domaine problématique. Cependant, des modèles de conception spécifiques s’appliquent à des domaines et des technologies à problèmes spécifiques.

Tous ceux qui pensent à ce qu’ils font découvriront des modèles de conception.

Les commentaires de Brian sur le lien étroit entre la langue et le modèle sont pertinents,

La partie manquante de cette discussion est le concept d’idiome. Le livre de Coplien, “Advanced C ++”, a eu une énorme influence ici. Bien avant de découvrir Christopher Alexander et la Colonne sans nom (et vous ne pouvez pas parler de manière raisonnable sans lire Alexander non plus), il a parlé de l’importance de maîsortingser l’idiome pour vraiment apprendre une langue. Il a utilisé la copie de chaîne en C comme exemple, alors que (* de ++ = * à ++); Vous pouvez voir cela comme un pansement pour une fonctionnalité de langue manquante (ou une fonction de bibliothèque), mais ce qui compte vraiment, c’est que c’est une unité de pensée ou d’expression plus grande que n’importe laquelle de ses parties.

C’est ce que les modèles et les langues essaient de faire pour nous permettre d’exprimer nos intentions plus succinctement. Plus les unités de pensée sont riches, plus les pensées que vous pouvez exprimer sont complexes. Avoir un vocabulaire riche et partagé à différentes échelles – de l’architecture système au bricolage – nous permet d’avoir des conversations plus intelligentes et de réfléchir à ce que nous devrions faire.

Nous pouvons aussi, en tant qu’individus, apprendre. Quel est le point entier de l’exercice. Nous pouvons chacun comprendre et utiliser des choses auxquelles nous ne pourrions jamais penser nous-mêmes. Les langues, les frameworks, les bibliothèques, les modèles, les idiomes, etc. ont leur place dans le partage de la richesse intellectuelle.

Le livre GOF se lie explicitement à la POO – le titre est Design Patterns – Elements of Réutilisable Object-Oriented Software (accent mis sur le mien).

Les schémas de conception dans la programmation dynamic de Peter Norvig couvrent de manière approfondie ce thème général, bien que les langages «dynamics» au lieu de «fonctionnels» (il y a un chevauchement).

Voici un autre lien, traitant de ce sujet: http://blog.ezyang.com/2010/05/design-patterns-in-haskel/

Dans son article, Edward décrit les 23 modèles originaux du GoF en termes de Haskell.

Lorsque vous essayez de regarder cela au niveau des «modèles de conception» (en général) et de «FP contre OOP», les réponses que vous trouverez seront au mieux obscures.

Approfondissez les niveaux sur les deux axes et prenez en compte des modèles de conception spécifiques, des fonctionnalités de langage spécifiques et les choses deviennent plus claires.

Ainsi, par exemple, certains modèles spécifiques, tels que Visitor , Strategy , Command et Observer, changent ou disparaissent définitivement en utilisant un langage avec des types de données algébriques et des correspondances de modèles , des fermetures , des fonctions de première classe , etc. «restr autour», cependant.

En général, je dirais que, au fil du temps, les nouveaux modèles (ou simplement la montée en popularité) éliminent certains modèles. C’est le cours naturel de la conception du langage; À mesure que les langues deviennent de plus en plus de haut niveau, les abstractions qui, auparavant, ne pouvaient être appelées que dans un livre, à l’aide d’exemples, deviennent maintenant des applications d’une fonction linguistique ou d’une bibliothèque particulière.

(À part: voici un blog récent que j’ai écrit, qui contient d’autres liens vers d’autres discussions sur les modèles de PF et de conception.)

La présentation de Norvig fait allusion à une parsing qu’ils ont faite de tous les modèles du GoF, et ils affirment que 16 des 23 modèles avaient des implémentations plus simples dans les langages fonctionnels, ou faisaient simplement partie du langage. Donc probablement au moins sept d’entre eux étaient soit a) aussi compliqués, soit b) non présents dans la langue. Malheureusement pour nous, ils ne sont pas énumérés!

Je pense qu’il est clair que la plupart des modèles “créatifs” ou “structurels” de GoF ne sont que des astuces pour obtenir les systèmes de types primitifs en Java ou en C ++ pour faire ce que vous voulez. Mais le rest mérite d’être considéré, quelle que soit la langue dans laquelle vous programmez.

On pourrait être Prototype; Bien qu’il s’agisse d’une notion fondamentale de JavaScript, elle doit être mise en œuvre dans d’autres langues.

L’un de mes modèles préférés est le modèle d’object nul: représente l’absence de quelque chose en tant qu’object qui ne fait rien. Cela peut être plus facile à modéliser dans un langage fonctionnel. Cependant, le véritable accomplissement est le changement de perspective.

Je dirais que lorsque vous avez un langage comme Lisp avec son support pour les macros, vous pouvez construire vos propres abstractions spécifiques à un domaine, des abstractions qui sont souvent bien meilleures que les solutions idiomatiques générales.

Et même les solutions OO Design Pattern sont spécifiques au langage. Les modèles de conception sont des solutions aux problèmes courants que votre langage de programmation ne résout pas pour vous. En Java, le motif Singleton résout le problème unique (simplifié). En Scala, vous avez une construction de niveau supérieur appelée Object en plus de Class. C’est instancié paresseusement et il n’y en a qu’un. Vous n’avez pas besoin d’utiliser le modèle Singleton pour obtenir un Singleton. Cela fait partie de la langue.

Comme d’autres l’ont dit, il existe des modèles spécifiques de functional programming. Je pense que le problème de la suppression des modèles de conception n’est pas tant une question de fonctionnalités, mais une question de fonctionnalités linguistiques .

Jetez un coup d’œil à la façon dont Scala supprime le “motif singleton”: vous déclarez simplement un object au lieu d’une classe. Une autre caractéristique, la correspondance des motifs, permet d’éviter le caractère désordonné du motif du visiteur. Voir la comparaison ici: http://andymaleh.blogspot.com/2008/04/scalas-pattern-matching-visitor-pattern.html

Et Scala, comme F #, est une fusion de OO-fonctionnelle. Je ne sais pas pour F # mais il a probablement ce genre de fonctionnalités.

Les fermetures sont présentes dans un langage fonctionnel, mais ne doivent pas nécessairement être limitées à celles-ci. Ils aident avec le modèle de délégué.

Une autre observation. Ce morceau de code implémente un pattern: il est tellement classique et élémentaire que nous ne le considérons généralement pas comme un “pattern”, mais il est certain que:

 for(int i = 0; i < myList.size(); i++) { doWhatever(myList.get(i)); } 

Les langages impératifs comme Java et C # ont adopté ce qui est essentiellement une construction fonctionnelle pour traiter de ceci: "foreach".

Les schémas sont des moyens de résoudre des problèmes similaires qui se répètent, puis sont décrits et documentés. Donc, non, FP ne va pas remplacer les modèles; Cependant, FP pourrait créer de nouveaux modèles et rendre certains modèles de “meilleures pratiques” actuels “obsolètes”.

Les modèles de conception GoF sont des recettes de contournement de codage pour les langages OO qui sont des descendants de Simula 67, tels que Java et C ++.

La plupart des “maux” traités par les modèles de conception sont causés par:

• des classes statiquement typées, qui spécifient des objects mais ne sont pas elles-mêmes des objects;
• ressortingction à un envoi unique (seul l’argument le plus à gauche est utilisé pour sélectionner une méthode, les arguments restants sont considérés comme des types statiques uniquement: s’ils ont des types dynamics, la méthode consiste à les sortinger avec des approches ad hoc);
• distinction entre les appels de fonctions réguliers et les appels de fonctions orientés object, ce qui signifie que les fonctions orientées object ne peuvent pas être transmises comme arguments fonctionnels lorsque des fonctions régulières sont attendues et vice versa; et
• distinction entre “types de base” et “types de classes”.

Il n’y a pas un seul de ces modèles de conception qui ne disparaît pas dans le système d’object Common Lisp, même si la solution est structurée essentiellement de la même manière que dans le modèle de conception correspondant. (En outre, ce système d’objects précède le livre GoF de plus de dix ans. Common Lisp est devenu la norme ANSI la même année où ce livre a été publié pour la première fois.)

En ce qui concerne la functional programming, le fait que les modèles s’y appliquent ou non dépend de si le langage de programmation fonctionnel donné possède une sorte de système d’object et s’il est modélisé d’après les systèmes d’object qui en bénéficient. Ce type d’orientation d’object ne se mélange pas bien avec la functional programming, car la mutation d’état est au centre et au premier plan.

La construction et l’access sans mutations sont compatibles avec la functional programming, de sorte que les modèles liés à l’access abstrait ou à la construction pourraient s’appliquer: modèles tels que Factory, Facade, Proxy, Decorator, Visitor.

D’un autre côté, les schémas comportementaux tels que l’état et la stratégie ne s’appliquent probablement pas directement à la POO fonctionnelle, car la mutation de l’état est au cœur de celle-ci. Cela ne signifie pas qu’ils ne s’appliquent pas; Peut-être qu’ils s’appliquent d’une manière ou d’une autre en combinaison avec les astuces disponibles pour simuler un état mutable.

Je voudrais append quelques articles excellents mais quelque peu denses de Jeremy Gibbons: “Les modèles de conception en tant que programmes génériques de type d’ordre supérieur” et “L’essence du modèle Iterator” (tous deux disponibles ici: http: // www. comlab.ox.ac.uk/jeremy.gibbons/publications/ ).

Ces deux méthodes décrivent comment les constructions fonctionnelles idiomatiques couvrent le terrain couvert par des modèles de conception spécifiques dans d’autres parameters (orientés object).

Vous ne pouvez pas avoir cette discussion sans mettre en place des systèmes de type.

Les principales caractéristiques de la functional programming comprennent des fonctions telles que des valeurs de première classe, des valeurs currying, des valeurs immuables, etc.

C’est parce que ces fonctionnalités ne répondent pas aux mêmes problèmes que la POO … ce sont des alternatives à la programmation impérative. La réponse de la FP à la POO se trouve dans les systèmes de types de ML et de Haskell … en particulier les types de sum, les types de données abstraits, les modules ML et les types Haskell.

Mais, bien sûr, il existe encore des modèles de conception qui ne sont pas résolus par les langages FP. Quel est l’équivalent FP d’un singleton? (Sans tenir compte un instant que les singletons sont généralement un modèle terrible à utiliser)

La première chose à faire est d’éliminer le besoin de singletons.

Vous pouvez parcourir la liste des 23 et en éliminer davantage, mais je n’ai pas le temps maintenant.

Je pense que seuls deux modèles de conception GoF sont conçus pour introduire la logique de functional programming dans le langage OO naturel. Je pense à la stratégie et au commandement. Certains des autres modèles de conception GoF peuvent être modifiés par functional programming afin de simplifier la conception et de conserver l’objective.

Essentiellement, oui !

• Lorsqu’un motif contourne les fonctionnalités manquantes (fonctions d’ordre élevé, gestion des stream …), cette dernière facilite la composition .
• La nécessité de réécrire encore et encore l’implémentation de modèles peut elle-même être considérée comme une odeur de langage .

En outre, cette page (AreDesignPatternsMissingLanguageFeatures) fournit une table de traduction “pattern / feature” et de bonnes discussions, si vous êtes prêt à creuser.

Les modèles OOP et GoF traitent des états. La POO modélise la réalité pour garder la base de code aussi proche que possible des exigences de la réalité. Les modèles de conception du GoF sont des modèles qui ont été identifiés pour résoudre les problèmes du monde réel. Ils traitent le problème de l’état de manière sémantique.

Comme dans la functional programming réelle, aucun état n’existe, l’application des modèles GoF n’a pas de sens. Il n’y a pas de modèles de conception fonctionnels de la même manière que les modèles de conception GoF. Chaque modèle de conception fonctionnelle est artificiel contrairement à la réalité, car les fonctions sont des constructions mathématiques et non pas la réalité.

Les fonctions n’ont pas le concept de temps car elles renvoient toujours la même valeur, quelle que soit l’heure courante, à moins que le temps fasse partie des parameters de la fonction, ce qui rend difficile le traitement des “demandes futures”. Les langages hybrides mélangent ces concepts, ce qui fait que les langages ne sont pas de véritables langages de programmation fonctionnels.

Les langages fonctionnels ne se multiplient que par une chose: les ressortingctions naturelles actuelles de la physique. Les processeurs actuels sont limités dans leur rapidité de traitement des instructions en raison des lois physiques. Vous voyez une stagnation de la fréquence d’horloge mais une expansion dans les cœurs de traitement. C’est pourquoi le parallélisme des instructions devient de plus en plus important pour augmenter la vitesse des applications modernes. Comme la functional programming par définition n’a pas d’état et n’a donc aucun effet secondaire, il est possible de traiter des fonctions en toute sécurité en parallèle.

Les patrons GoF ne sont pas obsolètes. Ils sont au moins nécessaires pour modéliser les exigences du monde réel. Mais si vous utilisez un langage de programmation fonctionnel, vous devez les transformer en leurs équivalents hybrides. Enfin, vous n’avez aucune chance de faire uniquement des programmes fonctionnels si vous utilisez la persistance. Pour les éléments hybrides de votre programme, il rest la nécessité d’utiliser les modèles GoF. Tout autre élément purement fonctionnel n’a pas besoin d’utiliser des patterns GoF car il n’ya pas d’état.

Parce que le modèle GoF n’est pas nécessaire pour une functional programming réelle, cela ne signifie pas que les principes SOLID ne doivent pas être appliqués. Les principes SOLID dépassent tout paradigme linguistique.

La functional programming ne remplace pas les modèles de conception. Les motifs de conception ne peuvent pas être remplacés.

Les modèles existent simplement; ils ont émergé avec le temps. Le livre GoF en a formalisé certains. Si de nouveaux modèles apparaissent au fur et à mesure que les développeurs utilisent des langages de programmation fonctionnels passionnants, il y aura peut-être aussi des livres à leur sujet.

Dans le nouveau livre de 2013 intitulé “Patterns de functional programming dans Scala et Clojure”, l’auteur Michael.B. Linn fait un travail décent en comparant et en fournissant des remplacements dans de nombreux cas pour les patrons GoF et discute également des nouveaux modèles fonctionnels tels que la «récursion de la queue», la «mémorisation», la «séquence paresseuse», etc.

Ce livre est disponible sur Amazon. Je l’ai trouvé très instructif et encourageant lorsque je suis issu d’une expérience de deux décennies.

Je pense que chaque paradigme sert un objective différent et, en tant que tel, ne peut être comparé de cette manière.

Je n’ai pas entendu dire que les modèles de conception du GoF sont applicables à toutes les langues. J’ai entendu dire qu’ils sont applicables à toutes les langues de la POO . Si vous utilisez la functional programming, le domaine des problèmes que vous résolvez est différent des langages OO.

Je n’utiliserais pas de langage fonctionnel pour écrire une interface utilisateur, mais l’un des langages OO comme C # ou Java faciliterait ce travail. Si j’écrivais un langage fonctionnel, je ne penserais pas à utiliser des modèles de conception OO.

La POO et la PF ont des objectives différents, la POO vise à encapsuler les complexités / parties mobiles des composants logiciels et la PF vise à minimiser la complexité et les dépendances des composants logiciels, mais ces deux paradigmes ne sont pas nécessairement contradictoires. des deux mondes. Même avec un langage qui ne supporte pas nativement la functional programming comme C #, vous pourriez écrire du code fonctionnel si vous comprenez les principes de PF, de même vous appliquez les principes de la POO si vous comprenez les principes, modèles et meilleures pratiques de la POO. Vous feriez le bon choix en fonction de la situation et du problème que vous tentez de résoudre, quel que soit le langage de programmation que vous utilisez.

Comme l’a dit la réponse acceptée, la POO et la PF ont toutes des modèles spécifiques.

Cependant, certains modèles sont si courants que toutes les plates-formes de programmation auxquelles je peux penser devraient exister. Voici une liste (incomplète):

• Adaptateur. Je ne peux guère penser à une plate-forme de programmation utile qui soit si complète (et auto-réalisée) qu’elle n’a pas besoin de parler au monde. Si tel est le cas, un adaptateur est absolument nécessaire.

• Façade. Toute plate-forme de programmation capable de gérer du code source volumineux devrait pouvoir être modularisée. Si vous deviez créer un module pour d’autres parties du programme, vous souhaiterez masquer les parties “sales” du code et lui donner une interface agréable.

• Interprète. En général, tout programme ne fait que deux choses: parsingr les entrées et imprimer les résultats. Les entrées de souris doivent être analysées et les widgets de fenêtre doivent être imprimés. Par conséquent, avoir un interpréteur intégré donne au programme une puissance supplémentaire pour personnaliser les choses.

En outre, j’ai remarqué dans un langage typique de PF, Haskell, qu’il y avait quelque chose de similaire aux modèles GoF, mais avec des noms différents. À mon avis, cela suggère qu’ils étaient présents car il y a des problèmes communs à résoudre à la fois dans les langues de la PF et de la POO.

• Transformateur et décorateur Monad. Le premier permettant d’append des capacités supplémentaires dans une monade existante, les seconds ajoutent une capacité supplémentaire à un object existant.