Où sont tous les modèles de conception de programmation fonctionnelle? [fermé]

La littérature de programmation OO est pleine de modèles de conception. La plupart des livres sur la programmation orientée objet consacrent un chapitre ou deux à la conception de motifs tels que des usines et des décorateurs. Alors, quels sont les modèles équivalents dans les langages fonctionnels et pourquoi personne n’a encore écrit de livre à leur sujet? Y a-t-il quelque chose de spécial dans les langages fonctionnels qui évite le besoin de modèles de conception?

OO et la programmation fonctionnelle sont deux paradigmes de programmation très différents, et les modèles de conception (DP) constituent une partie importante de la conception et de la programmation OO. Les PD n'ont pas ce rôle dans la programmation fonctionnelle.

On pourrait même dire que les DP ne sont pas nécessaires dans la programmation fonctionnelle - il n'y a pas de démangeaisons contre celles-ci.

• On pourrait soutenir que les modèles de conception sont un signe de fonctionnalités manquantes dans un langage de programmation.

• Peter Norvig a découvert que 16 des 23 modèles du livre Design Patterns sont " soit invisibles, soit simples " en Lisp ou en Dylan.

• "De nombreux modèles impliquent une orientation d'objet ou plus généralement un état mutable, et peuvent donc ne pas être aussi applicables dans les langages de programmation fonctionnels, dans lesquels les données sont immuables ou traitées comme telles." - http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29

Jeremy Gibbons écrit le livre. En attendant, vous pouvez lire son blog, Patterns in Functional Programming . Il recommande de lire ses messages du plus ancien au plus récent.

Parcourez également ses publications . Il couvre quatre modèles dans les modèles de conception en tant que programmes génériques de type de données d'ordre supérieur et décrit les modèles de programmation avec des équations récursives dans la programmation en origami (plis et dépliés).

Le simple fait est que de nombreux modèles OO seraient considérés comme des idiomes dans les langages fonctionnels (en particulier les modèles GoF d'origine). Par exemple, le modèle Iterator (intégré à des langages tels que C # maintenant) n’est tout simplement pas nécessaire dans un Lisp ou ML qui a des opérateurs de séquence.

Une grande partie des modèles que nous utilisons dans les systèmes OO sont là pour nous aider à éliminer les éléments "non essentiels" afin que nous puissions nous concentrer sur les objets de codage. En d'autres termes, les modèles sont des solutions aux parties non intéressantes de l'application. Nous devons tirer parti des modèles pour répondre aux besoins communs qui ont été résolus auparavant (tels que les modèles de Fowlers Patterns of Enterprise Application Architecture permettant de traiter des problèmes tels que la transmission de bases de données ou xUnit Patterns pour optimiser vos tests unitaires) afin de pouvoir nous concentrer sur l'ajout de valeur commerciale. pour l'application.

Je suis sûr qu’au-delà des spécificités des modèles GoF, il existe également des modèles de conception applicables à la programmation fonctionnelle. La chose est que OO est le paradigme dominant. Écrire un cahier de modèles qui cible les développeurs fonctionnels ... eh bien franchement, un éditeur ne donnera pas son feu vert. C'est ce que cela revient à. Il n’existe pas suffisamment de marché pour que les modèles fonctionnels disposent d’un nombre important de livres consacrés à ce sujet.

Une bonne discussion (~ 45 min) sur ce sujet par Stuart Sierra:

http://www.infoq.com/presentations/Clojure-Design-Patterns

Pas nécessairement contraignant et faisant autorité, mais j'ai reconnu un certain nombre de ses exemples à partir de ma propre expérience d'utilisation de la PF pour l'analyse de données.

Exemples écrits en langage Clojure, mais probablement applicables à n’importe quel langage de PF. Les noms qu'il donne aux motifs qu'il couvre sont:

• Etat / événement
• Conséquences
• Accumulateur
• Réduire / Combiner
• Expansion récursive
• Pipeline
• Wrapper
• Jeton
• Observateur
• Stratégie

Si vous souhaitez réellement apprendre les motifs, ne cherchez pas plus loin que Haskell. Si vous prenez le temps d' apprendre la langue à la dure, ce que vous rencontrerez et vous familiariserez avec la plupart des tendances fondamentales - elles sont intégrées à la langue.

Ne sautez pas les monades. Il existe de nombreuses explications de longue haleine et il faut un certain effort pour intégrer les idées, mais si vous continuez à vous débrouiller, cela finira par vous apparaître et vous serez étonné du nombre de modèles de conception pouvant être utilisés. construire sur cette abstraction / interface.

Une fois que vous aurez utilisé Haskell, vous aurez suffisamment d’arsenal de PF à votre disposition pour être dangereux. Le point est, continuez jusqu'à ce que vous l'obteniez. Il n'y a pas de raccourci.

Dans la mesure où la méthodologie de conception de la PF consiste à concevoir vos types de manière à refléter avec précision l'espace du problème et que la mise en œuvre devrait suivre automatiquement, l'équivalent d'un livre sur les modèles de conception de FP ressemble à celui des structures de données purement fonctionnelles de Chris Okasaki .