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

75

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?

davidk01
la source
6
Il existe certainement des modèles de conception fonctionnels - prenez des mémos ou des monades par exemple - je me demande également si quelqu'un les a rassemblés au même endroit ...
FinnNk
2
FinnNk Monad est plus une classe de types qu'un modèle de conception ^ _ ^
alternative Le
Pour haskell, Gabriel Gonzalez a publié
bennofs le
1
Carte réduite est un. Je suis déçu qu'il n'y ait pas une bonne liste de modèles
Sridhar Sarnobat

Réponses:

48

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.

Maglob
la source
41
Je ne suis pas sûr de convenir que les modèles de conception ne s'appliquent pas à la PF. La PF présente encore des problèmes communs qui doivent être résolus en particulier, des moyens communs. Différents problèmes à ceux résolus dans OO, mais toujours des problèmes quand même. Je pense que c'est probablement juste quelque chose qui a reçu beaucoup moins d'attention que dans OO, puisque la PF est moins répandue dans le monde commercial à l'heure actuelle.
d11wtq
22
Affirmer que le motif de conception n'existe pas dans la programmation fonctionnelle est une désinformation. Le plus simple contre-exemple est la monade. Vous n’avez pas besoin d’utiliser Monad dans la programmation fonctionnelle, mais c’est un modèle très courant que les gens suivent pour faciliter l’application de la programmation à fonction pure. C'est essentiellement la définition du modèle de conception.
voidvector
3
Les modèles de conception s'appliquent à toutes les activités de conception, qu'il s'agisse de programmation ou de conception de maison. En fait, les concepts mêmes des langages de motifs proviennent de l'architecture: en.wikipedia.org/wiki/A_Pattern_Language .
BobDalgleish
2
Hmm. Flux observables, validation ferroviaire et enfer, pratiquement chaque monade est un modèle de conception, non?
Chet
2
@voidvector Les monades ne sont pas simplement un motif. En FP, les monades sont utilisées comme foncteurs entre les systèmes de types, et le concept lui-même provient de la théorie des catégories, une branche des mathématiques. Ils sont utilisés pour décrire un type particulier de relations entre des structures algébriques en général. Il serait plus exact de dire que la programmation fonctionnelle est un dattern de conception facilitant l'utilisation des mathématiques dans la programmation.
John Cramerus
67

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).

Corbin March
la source
13

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.

Michael Brown
la source
9

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
Aaron Johnson
la source
6

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.

Mario T. Lanza
la source
-3

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 .

geekosaur
la source
1
Le livre d'Okasaki est l'équivalent de la partie structure de données de nombreux livres de structure de données et d'algorithmes qui ne prennent généralement en compte que la structure de données mutable.
AProgrammer
1
Je ne pense pas que l’équivalence entre les structures de données et les modèles de conception convient au projet de loi. Ce n'est pas comme si les programmeurs OO agitent les bras jusqu'à ce que les définitions de classe appropriées apparaissent.
davidk01
Oui, le livre d'Okasaki est à un niveau inférieur aux modèles de conception.
FinnNk