Où sont tous les modèles de conception de programmation fonctionnelle?
La littérature de programmation OO regorge de modèles de conception. La plupart des livres sur la programmation orientée objet consacrent un ou deux chapitres à la conception de modèles comme les usines et les décorateurs. Alors, quels sont les modèles équivalents dans les langages fonctionnels et pourquoi personne n'a encore écrit un 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) sont une partie importante de la conception et de la programmation OO. DP n'a pas un tel rôle dans la programmation fonctionnelle.
On pourrait même dire que le DP n'est pas nécessaire dans la programmation fonctionnelle - il n'y a aucune démangeaison pour laquelle le DP est guéri.
On pourrait soutenir que les modèles de conception sont un signe de fonctionnalités manquantes dans un langage de programmation.
Peter Norvig trouvé que 16 des 23 modèles du livre Design Patterns sont " soit invisibles soit simples) r "dans LISP ou Dylan.
"De nombreux modèles impliquent une orientation objet ou un état plus généralement 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. Jusqu'à ce qu'il soit terminé, 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 Gang of Four patterns in ( Design Patterns as Higher-Order Datatype-Generic Programs et décrit les modèles de programmation avec récursivité équations en ( Programmation Origami (se plie et se déplie).
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é aux langages comme C # maintenant) n'est tout simplement pas '' t nécessaire dans un LISP ou ML qui a des opérateurs de séquence.
Un grand nombre des modèles que nous utilisons dans les systèmes O-O sont là pour nous aider à éliminer les "éléments non essentiels" afin que nous puissions nous concentrer sur le codage des objets. 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 (comme les modèles dans Fowlers Patterns of Enterprise Application Architecture pour gérer des choses comme la transmission de bases de données ou les modèles xUnit pour booster vos tests unitaires) afin que nous puissions 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 des modèles de conception qui seront également applicables à la programmation fonctionnelle. Le fait est que O-O est le paradigme dominant. Écrire un livre de patrons qui cible les développeurs fonctionnels ... bien franchement ne recevra pas le feu vert d'un éditeur. Voilà à quoi cela se résume. Il n'y a pas assez de marché pour les modèles fonctionnels pour avoir un nombre important de livres consacrés au sujet.
Un bon discours (~ 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 de ma propre expérience en utilisant FP pour l'analyse des données.
Exemples écrits en Clojure, mais probablement applicables à n'importe quelle langue FP. Les noms qu'il donne aux modèles qu'il couvre sont:
- État/événement
- Conséquences
- Accumulateur
- Réduire/combiner
- Expansion récursive
- Pipeline
- Wrapper
- Jeton
- Observateur
- Stratégie
Si vous êtes vraiment intéressé à apprendre les modèles de conception, ne cherchez pas plus loin que Haskell. Si vous prenez le temps de apprendre la langue à la dure vous allez rencontrer et vous familiariser avec la plupart des modèles fondamentaux - ils sont intégrés dans la langue.
Ne sautez pas les monades. Il y a un tas d'explications de longue haleine et il faut un peu de temps pour que les idées s'enfoncent, mais si vous continuez à vous éloigner, cela finira par vous apparaître et vous serez étonné de voir combien de modèles de conception peuvent être construire au-dessus de cette abstraction/interface.
Une fois que vous aurez grogné Haskell, vous aurez suffisamment de l'arsenal FP à votre disposition pour être dangereux. Le point est, continuez jusqu'à ce que vous l'obteniez. Il y a pas de raccourcis.