La programmation fonctionnelle remplace-t-elle les modèles de conception GoF?
Depuis que j'ai commencé à apprendre F # et OCaml l'année dernière, j'ai lu un grand nombre d'articles qui insistent sur le fait que les modèles de conception (en particulier en Java) constituent une solution de contournement pour les fonctionnalités manquantes des langages impératifs. Un article que j'ai trouvé fait une affirmation assez forte :
La plupart des personnes que j'ai rencontrées ont lu le livre Design Patterns du Gang of Four. Tout programmeur qui se respecte se dira que le livre est indépendant de la langue et que les modèles s’appliquent au génie logiciel en général, quelle que soit la langue que vous utilisez. C'est une noble revendication. Malheureusement, il est loin de la vérité.
Les langages fonctionnels sont extrêmement expressifs. Dans un langage fonctionnel, vous n'avez pas besoin de modèles de conception, car le langage utilisé est si élevé que vous finissez par programmer dans des concepts qui éliminent tous les modèles de conception.
Les principales caractéristiques de la programmation fonctionnelle incluent des fonctions telles que des valeurs de première classe, le currying, des valeurs immuables, etc. Il ne me semble pas évident que les modèles de conception OO se rapprochent de ces caractéristiques.
En outre, dans les langages fonctionnels prenant en charge OOP (tels que F # et OCaml), il me semble évident que les programmeurs utilisant ces langages utiliseraient les mêmes modèles de conception que ceux disponibles pour les autres OOP la langue. En fait, à l’heure actuelle, j’utilise F # et OCaml tous les jours et il n’existe aucune différence frappante entre les modèles que j’utilise dans ces langages et ceux que j’utilise lorsque j’écris en Java.
Est-il vrai que l'affirmation selon laquelle la programmation fonctionnelle élimine le besoin de OOP modèles de conception? Si tel est le cas, pouvez-vous publier ou associer un exemple de modèle de conception typique OOP et son équivalent fonctionnel?
Le blog que vous avez cité exagère un peu sa revendication. FP n'élimine pas le besoin de modèles de conception. Le terme "modèles de conception" n'est tout simplement pas très utilisé pour décrire la même chose dans les langages FP. Mais ils existent. Les langages fonctionnels ont de nombreuses règles de bonne pratique de la forme "lorsque vous rencontrez un problème X, utilisez un code qui ressemble à Y", ce qui est fondamentalement ce qu'un modèle de conception est.
Cependant, il est exact que la plupart des modèles de conception spécifiques à la programmation orientée objet ne sont pratiquement pas pertinents dans les langages fonctionnels.
Je ne pense pas qu'il devrait être particulièrement controversé de dire que les modèles de conception en général n'existent que pour corriger les lacunes du langage. Et si une autre langue peut résoudre le même problème de manière triviale, cette autre langue n’aura pas besoin d’un modèle de conception. Les utilisateurs de cette langue peuvent même ne pas être conscients que le problème existe , car, eh bien, ce n'est pas un problème dans cette langue.
Voici ce que la bande des quatre a à dire sur cette question:
Le choix du langage de programmation est important car il influence le point de vue de chacun. Nos modèles reposent sur 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 avions supposé des langages procéduraux, nous aurions peut-être inclus des modèles de conception appelés "Héritage", "Encapsulation" et "Polymorphisme". De même, certains de nos modèles sont directement pris en charge par les langages orientés objet, moins courants. CLOS a plusieurs méthodes, par exemple, qui réduisent la nécessité d’un modèle tel que Visiteur. 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 une 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 programmation fonctionnelle incluent des fonctions telles que des valeurs de première classe, le currying, des valeurs immuables, etc. Il ne me semble pas évident que les modèles de conception OO se rapprochent de ces caractéristiques.
Quel est le modèle de commande, sinon une approximation de fonctions de première classe? :) Dans un langage FP, vous passez simplement une fonction en tant qu'argument à une autre fonction. Dans un langage OOP, vous devez envelopper la fonction dans une classe, que vous pouvez instancier, puis transmettre cet objet à l'autre fonction. L'effet est identique, mais dans OOP, cela s'appelle un motif de conception et nécessite beaucoup plus de code. Et quel est le modèle d'usine abstrait, sinon currying? Passez des paramètres à une fonction petit à petit pour configurer le type de valeur qu’elle crache lorsque vous l’appelez.
Alors oui, plusieurs modèles de conception GoF sont redondés dans FP langages, car il existe des alternatives plus puissantes et plus faciles à utiliser.
Mais bien sûr, il existe encore des modèles de conception qui ne sont pas résolus par FP langues. Quel est l'équivalent FP d'un singleton? (Ignorer 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 également ses propres modèles, 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 global"? C’est un problème qui est si simple dans les langages OOP qu’aucun modèle de conception équivalent n’y existe.
Nous n'avons pas besoin d'un modèle de conception pour "incrémenter une variable statique" ou "lire à partir de ce socket", car c'est exactement ce que vous faites .
Dire une monade est un motif de conception est aussi absurde que de dire que les entiers avec leurs opérations habituelles et zéro élément est un motif de conception. Non, une monade est un motif mathématique, pas un motif de conception.
Dans les langages fonctionnels (purs), les effets secondaires et l'état mutable sont impossibles, à moins de contourner le problème avec le "motif de conception" de la monade ou avec l'une des autres méthodes permettant d'obtenir le même résultat.
En outre, dans les langages fonctionnels prenant en charge OOP (tels que F # et OCaml), il me semble évident que les programmeurs utilisant ces langages utiliseraient les mêmes modèles de conception que ceux disponibles pour les autres OOP la langue. En fait, à l’heure actuelle, j’utilise F # et OCaml tous les jours, et il n’existe aucune différence frappante entre les modèles que j’utilise dans ces langages et ceux que j’utilise lorsque j’écris en Java.
Peut-être parce que tu penses toujours impérieusement? Beaucoup de gens, après avoir manipulé des langues impératives toute leur vie, ont du mal à renoncer à cette habitude lorsqu'ils essaient une langue fonctionnelle. (J'ai vu quelques tentatives assez amusantes de fa #, où littéralement chaque fonction était juste une chaîne d'instructions 'let', essentiellement comme si vous pris un programme en C et remplacé tous les points-virgules par 'let'. :))
Mais une autre possibilité pourrait être que vous ne réalisiez tout simplement pas que vous résolvez des problèmes de manière triviale nécessitant des modèles de conception dans un langage OOP.
Lorsque vous utilisez currying, ou passez une fonction comme argument à un autre, arrêtez-vous et réfléchissez à la manière de le faire dans une langue OOP.
Est-il vrai que l'affirmation selon laquelle la programmation fonctionnelle élimine le besoin de OOP modèles de conception?
Oui. :) Lorsque vous travaillez dans une langue FP, vous n'avez plus besoin des modèles de conception spécifiques à la POO. Cependant, vous avez encore besoin de modèles de conception généraux, tels que MVC ou d'autres éléments spécifiques non liés à la POO, et de nouveaux "modèles de conception" spécifiques à la PF. Toutes les langues ont leurs faiblesses et les schémas de conception sont généralement la manière dont nous les travaillons.
Quoi qu’il en soit, vous trouverez peut-être intéressant de vous essayer aux langues "plus propres" FP, comme ML (mon préféré, au moins à des fins d’apprentissage), ou à Haskell, où vous n’avez pas le OOP béquille sur laquelle vous pouvez vous appuyer lorsque vous faites face à quelque chose de nouveau.
Comme prévu, quelques personnes se sont opposées à ma définition des modèles de conception comme "corrigeant les lacunes d'un langage", voici donc ma justification: comme déjà dit, la plupart des modèles de conception sont spécifiques à un paradigme de programmation, voire parfois à un langage spécifique. Souvent, ils résolvent des problèmes qui n'existent que dans ce paradigme (voir monades pour FP, ou usines abstraites pour OOP). Pourquoi le modèle d'usine abstraite n'existe-t-il pas dans FP? Parce que le problème qu’il essaie de résoudre n’existe pas là-bas. Donc, si un problème existe dans OOP langues, ce qui n'existe pas dans FP langues, il est clair qu'il s'agit d'un inconvénient de OOP langues. Le problème peut être résolu, mais votre langue ne le fait pas, mais vous avez besoin d'un tas de code passe-partout pour la résoudre. Idéalement, nous aimerions que notre langage de programmation fasse disparaître comme par magie tous les problèmes . Tout problème qui existe encore est en principe une lacune de la langue. ;)
Est-il vrai que l'affirmation selon laquelle la programmation fonctionnelle élimine le besoin de OOP modèles de conception?
La programmation fonctionnelle n'est pas la même que la programmation orientée objet. Les modèles de conception orientés objet ne s'appliquent pas à la programmation fonctionnelle. Au lieu de cela, vous avez des modèles de conception de programmation fonctionnels.
Pour une programmation fonctionnelle, vous ne lirez pas les livres de modèles de conception OO, vous lirez d'autres livres sur les modèles de conception FP.
langue agnostique
Pas totalement. Seule la langue agnostique par rapport à OO langues. Les modèles de conception ne s'appliquent pas du tout aux langages procéduraux. Ils ont à peine un sens dans un contexte de conception de base de données relationnelle. Ils ne s'appliquent pas à la conception d'un tableur.
un modèle de conception OOP typique et son équivalent fonctionnel?
Ce qui précède ne devrait pas exister. C'est comme demander un morceau de code de procédure réécrit en tant que code OO. Ummm ... Si je traduis l'original Fortran (ou C) en Java, je n'ai rien fait de plus que de le traduire. Si je le réécris totalement dans un paradigme OO, il ne ressemblera plus du tout à l'original Fortran ou C - il sera méconnaissable.
Il n'y a pas de mappage simple de OO Design à la conception fonctionnelle. Ce sont des manières très différentes de voir le problème.
La programmation fonctionnelle (comme tous 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 - sont une manière intemporelle de construire, 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 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 qui existe entre le langage et les habitudes sont pertinents,
La partie manquante de cette discussion est le concept d'idiome. Le livre de Coplien, "Advanced C++", a eu une influence considérable ici. Bien avant de découvrir Christopher Alexander et le Column Without a Name (et vous ne pouvez pas parler de motifs sans lire Alexandre non plus), il a parlé de l'importance de maîtriser l'idiome pour vraiment apprendre une langue. Il a utilisé la copie de chaîne en C à titre d'exemple, while (* de ++ = * à ++); Vous pouvez voir cela comme un pansement pour un élément de langue manquant (ou un élément de bibliothèque), mais ce qui compte vraiment, c’est que c’est une unité de pensée ou d’expression plus importante que n’importe laquelle de ses parties.
C’est ce que les modèles et les langages 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. Disposer d’un vocabulaire riche et partagé à différentes échelles - de l’architecture du système jusqu’au tour à tour - 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. Chacun de nous peut comprendre et utiliser des choses que nous ne pourrions jamais penser à nous-mêmes. Les langages, les frameworks, les bibliothèques, les patterns, les idiomes, etc. ont tous leur place dans le partage de la richesse intellectuelle.
Le livre GOF se lie explicitement à OOP - le titre est Design Patterns - Elements of Reusable Orienté Objet Logiciel (l'emphase est mineure.)
Modèles de conception dans la programmation dynamique par Peter Norvig couvre de manière réfléchie ce thème général, bien qu’il s’agisse de langages "dynamiques" au lieu de "fonctionnels" (il ya chevauchement).
Voici un autre lien, traitant de ce sujet: http://blog.ezyang.com/2010/05/design-patterns-in-haskel/
Dans son blog, Edward décrit les 23 modèles originaux de 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 versus OOP", les réponses que vous trouverez seront au mieux obscures.
Cependant, approfondissez un niveau sur les deux axes et considérez des modèles de conception spécifiques et des fonctionnalités de langage spécifiques et les choses deviennent plus claires.
Ainsi, par exemple, certains modèles spécifiques, tels que Visiteur , Stratégie , Commande , et L'observateur change ou disparaît définitivement lors de l'utilisation d'une langue avec Types de données algébriques et correspondance de modèle , fermetures , Fonctions de première classe , etc. Cependant, certains modèles du livre GoF restent "persistants".
En général, je dirais que, au fil du temps, des caractéristiques spécifiques sont éliminées par les nouvelles fonctionnalités linguistiques (ou leur popularité croissante). C'est le cours naturel de la conception du langage; Au fur et à mesure que les langues deviennent de plus en plus avancées, les abstractions qui n'étaient auparavant appelées que dans un livre à l'aide d'exemples deviennent désormais des applications d'une fonctionnalité ou d'une bibliothèque particulière.
(A part: voici un blog récent j'ai écrit, qui contient d'autres liens pour en savoir plus sur les discussions sur FP et les modèles de conception.)
La présentation de Norvig fait allusion à une analyse qu'ils ont faite de tous les modèles GoF, et ils disent que 16 des 23 modèles avaient des implémentations plus simples dans les langages fonctionnels, ou faisaient simplement partie du langage. Donc, vraisemblablement, au moins sept d’entre eux étaient a) également compliqués ou b) n’étaient pas 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" dans le GoF ne sont que des astuces pour obtenir les systèmes de types primitifs dans Java ou C++ à faire ce que vous voulez. Mais les autres méritent d’être pris en considération, quelle que soit la langue dans laquelle vous programmez.
On pourrait être Prototype; Bien qu'il s'agisse d'une notion fondamentale de JavaScript, il doit être implémenté à partir de zéro dans d'autres langages.
Un de mes modèles préférés est le modèle Null Object: représente l'absence de quelque chose en tant qu'objet ne faisant rien de approprié. Cela peut être plus facile à modéliser dans un langage fonctionnel. Cependant, la véritable réalisation est le changement de perspective.
Je dirais que lorsque vous avez un langage comme LISP avec son support pour les macros, vous pouvez alors créer vos propres abstractions spécifiques à un domaine, 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 modèle Singleton résout le problème unique (simplifié). En Scala, vous disposez d'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'êtes pas obligé d'utiliser le modèle Singleton pour obtenir un Singleton. Cela fait partie de la langue.
Les modèles sont des moyens de résoudre des problèmes similaires qui sont vus maintes et maintes fois, puis décrits et documentés. Donc non, FP ne va pas remplacer les motifs; Toutefois, FP peut créer de nouveaux modèles et rendre "obsolètes" certains modèles de "meilleures pratiques" actuels.
Comme d'autres l'ont dit, il existe des schémas spécifiques à la programmation fonctionnelle. Je pense que le problème de la suppression des modèles de conception n’est pas tant une question de passage au fonctionnel, mais plutôt une question de fonctionnalités du langage .
Regardez comment Scala supprime le "modèle singleton": vous déclarez simplement un objet au lieu d'une classe. Une autre caractéristique, la correspondance de motifs, permet d’éviter la confusion du motif des visiteurs. 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-fonctionnel. Je ne sais pas à propos de F #, mais il a probablement ce genre de fonctionnalités.
Les fermetures sont présentes dans un langage fonctionnel, mais ne doivent pas être limitées à celles-ci. Ils aident avec le motif de délégation.
Une autre observation. Ce morceau de code implémente un motif: il est tellement classique et tellement élémentaire que nous ne le considérons généralement pas comme un "motif", mais il est certain que:
for(int i = 0; i < myList.size(); i++) { doWhatever(myList.get(i)); }
Des langages impératifs comme Java et C # ont adopté ce qui est essentiellement une construction fonctionnelle pour traiter ceci: "foreach".
Les modèles de conception GoF codent des recettes de solution de contournement pour les langages OO 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:
- classes statiquement typées, qui spécifient des objets mais ne sont pas elles-mêmes des objets;
- restriction à une seule distribution (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 dynamiques, il appartient à la méthode de les résoudre avec des approches ad hoc);
- distinction entre les appels de fonction normaux et les appels de fonction orientés objet, ce qui signifie que les fonctions orientées objet ne peuvent pas être transmises en tant qu'arguments fonctionnels lorsque des fonctions régulières sont attendues et inversement; et
- distinction entre "types de base" et "types de classe".
Il n’existe pas un seul de ces modèles de conception qui ne disparaisse pas dans le système d’objets LISP commun, même si la solution est structurée de la même manière que dans le modèle de conception correspondant. (En outre, ce système d'objets précède de plus de dix ans le livre GoF. Common LISP est devenu une norme ANSI la même année que ce livre a été publié.)
En ce qui concerne la programmation fonctionnelle, que les modèles s’appliquent ou non dépend de la question de savoir si le langage de programmation fonctionnel donné a un type de système objet et s’il est modelé sur les systèmes objets qui bénéficient des modèles. Ce type d'orientation-objet ne se mélange pas bien avec la programmation fonctionnelle, car la mutation d'état est à l'avant-plan.
La construction et l’accès non mutant sont compatibles avec la programmation fonctionnelle. Les modèles liés à l’abstraction de l’accès ou à la construction peuvent donc s’appliquer: modèles tels que Usine, Façade, Proxy, Décorateur, Visiteur.
Par ailleurs, les schémas comportementaux tels que État et Stratégie ne s’appliquent probablement pas directement dans les fonctions fonctionnelles OOP, car la mutation d’état est en cours. leur noyau. Cela ne signifie pas qu'ils ne s'appliquent pas; peut-être qu’elles s’appliquent d’une manière ou d’une autre en combinaison avec toutes les astuces disponibles pour simuler un état mutable.
Je voudrais ajouter quelques articles de Jeremy Gibbons, excellents mais un peu denses: "Design patterns en tant que programmes génériques de types de données d'ordre supérieur" et "The essence of the Iterator pattern" (tous deux disponibles ici: http: //www.comlab.ox.ac.uk/jeremy.gibbons/publications/ ).
Ces deux exemples décrivent comment les constructions fonctionnelles idiomatiques couvrent le terrain couvert par des modèles de conception spécifiques dans d'autres paramètres (orientés objet).
Vous ne pouvez pas avoir cette discussion sans évoquer des systèmes de types.
Les principales caractéristiques de la programmation fonctionnelle incluent des fonctions telles que des valeurs de première classe, le currying, des valeurs immuables, etc. Il ne me semble pas évident que les modèles de conception OO se rapprochent de ces caractéristiques.
En effet, ces fonctionnalités ne traitent pas les mêmes problèmes que OOP ... mais constituent une alternative à la programmation impérative. La réponse de FP à OOP réside dans les systèmes de types de ML et de Haskell ... en particulier des types de somme, des types de données abstraits, des modules de ML, des classes de type Haskell.
Mais bien sûr, il existe encore des modèles de conception qui ne sont pas résolus par FP langues. Quel est l'équivalent FP d'un singleton? (Ignorer un instant que les singletons sont généralement un modèle terrible à utiliser)
La première chose que font les classes est d'éliminer le besoin de singletons.
Vous pouvez parcourir la liste des 23 et en éliminer d’autres, mais je n’ai pas le temps de le faire maintenant.
Je pense que seuls deux modèles de conception GoF sont conçus pour introduire la logique de programmation fonctionnelle dans un langage naturel OO. Je pense à la stratégie et au commandement. Certains modèles de conception GoF peuvent être modifiés par programmation fonctionnelle pour simplifier la conception et conserver son objectif.
Essentiellement, oui !
- Lorsqu'un modèle contourne les fonctionnalités manquantes (fonctions d'ordre élevé, gestion du flux ...) qui ltimalty facilite composition .
- La nécessité de ré-écrire à plusieurs reprises la mise en œuvre des modèles peut elle-même être considérée comme une odeur de langage .
En outre, ceci page (AreDesignPatternsMissingLanguageFeatures)) fournit une table de traduction "modèle/fonctionnalité" et quelques discussions de Nice, si vous êtes prêt à creuser.
Les modèles OOP et GoF traitent avec les États. OOP modélise la réalité pour que la base de code soit aussi proche que possible des exigences de la réalité. Les modèles de conception GoF sont des modèles qui ont été identifiés pour résoudre les problèmes du monde réel atomique. Ils traitent le problème de l'état de manière sémantique.
Comme dans la programmation fonctionnelle réelle, il n’existe aucun état, il n’a pas de sens d’appliquer les modèles GoF. Il n’existe pas de modèles de conception fonctionnels de la même manière qu’il existe des 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 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 actuelle, à moins que le temps ne fasse partie des paramètres de la fonction, ce qui rend vraiment difficile le traitement préalable des "demandes futures". Les langages hybrides mélangent ces concepts font que les langages ne sont pas de vrais langages de programmation fonctionnels.
Les langages fonctionnels ne sont en hausse que pour une seule chose: les restrictions naturelles actuelles de la physique. Les processeurs d’aujourd’hui sont limités dans leur vitesse de traitement des instructions en raison de lois physiques. Vous constatez une stagnation de la fréquence d'horloge mais une expansion du nombre de cœurs de traitement. C’est pourquoi le parallélisme des instructions devient de plus en plus important pour accélérer les applications modernes. Par définition, la programmation fonctionnelle n’ayant pas d’état ni d’effets secondaires, elle permet de traiter les fonctions en toute sécurité en parallèle.
Les modèles 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 créer uniquement des programmes fonctionnels si vous utilisez la persistance. Pour les éléments hybrides de votre programme, il reste nécessaire d'utiliser des modèles GoF. Tout autre élément purement fonctionnel ne nécessite pas l'utilisation de modèles GoF car il n'y a pas d'état.
Parce que le modèle GoF n'est pas nécessaire pour une programmation fonctionnelle réelle, cela ne signifie pas que les principes SOLID ne doivent pas être appliqués. Les principes SOLID vont au-delà de tout paradigme linguistique.
Dans le nouveau livre de 2013 intitulé "Modèles de programmation fonctionnelle - dans Scala et Clojure" l'auteur Michael.B. Linn fait un travail décent en comparant et en fournissant des remplaçants dans de nombreux cas pour les modèles 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 quand je viens de OO années.
La programmation fonctionnelle ne remplace pas les modèles de conception. Les modèles de conception ne peuvent pas être remplacés.
Les modèles existent simplement; ils ont émergé avec le temps. Le livre du GoF en a officialisé quelques-uns. Si de nouveaux modèles apparaissent au fur et à mesure que les développeurs utilisent des langages de programmation fonctionnels, il s’agit peut-être de livres passionnants à leur sujet.
Dans la programmation fonctionnelle, les modèles de conception ont une signification différente. En fait, la plupart des OOP ne sont pas nécessaires dans la programmation fonctionnelle en raison du niveau d'abstraction plus élevé et de HOFs utilisés. comme blocs de construction.
Le principe d'un HOF signifie que les fonctions peuvent être transmises en tant qu'arguments à d'autres fonctions. et les fonctions peuvent renvoyer des valeurs.
Je pense que chaque paradigme sert un objectif 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 GoF sont applicables à toutes les langues. J'ai entendu dire qu'ils sont applicables à tous les langues POO. Si vous utilisez la programmation fonctionnelle, le domaine des problèmes que vous résolvez est différent de OO langages.
Je n'utiliserais pas un langage fonctionnel pour écrire une interface utilisateur, mais l'un des OO langages comme C # ou Java faciliterait ce travail. Si j’écrivais un langage fonctionnel, je n’envisagerais pas d’utiliser OO Design Patterns.
Comme le dit la réponse acceptée, OOP et FP ont tous leurs modèles spécifiques.
Cependant, certains modèles sont si courants que toutes les plates-formes de programmation auxquelles je pense devraient avoir. Voici une liste (incomplète):
Adaptateur. Je peux difficilement penser à une plate-forme de programmation utile qui est si complète (et auto-réalisée) qu’elle n’a pas besoin de parler au monde. Si cela se produit, un adaptateur est absolument nécessaire.
Façade. Toute plate-forme de programmation capable de gérer un code source volumineux devrait pouvoir être modulaire. Si vous deviez créer un module pour d'autres parties du programme, vous voudrez 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: analyser une entrée et imprimer une sortie. Les entrées de souris doivent être analysées et les widgets de fenêtre doivent être imprimés. Par conséquent, le fait d'avoir un interprète intégré donne au programme plus de pouvoir pour personnaliser les choses.
De plus, j'ai remarqué que dans un langage typique FP, Haskell, il y a quelque chose de similaire aux modèles GoF, mais avec des noms différents. À mon avis, cela donne à penser qu'ils étaient là parce qu'il existe des problèmes courants à résoudre dans les deux langues [FP et OOP].
- Transformateur et décorateur Monad. Les premiers ajoutaient des capacités supplémentaires à une monade existante, les derniers ajoutaient des capacités supplémentaires à un objet existant.
OOP et FP ont des objectifs différents, OOP vise à encapsuler les complexités/éléments mobiles des composants logiciels et FP vise à minimiser la complexité et les dépendances des composants logiciels Ces deux paradigmes ne sont pas nécessairement totalement contradictoires et pourraient être appliqués ensemble pour tirer parti des avantages des deux mondes. Même avec un langage qui ne supporte pas nativement la programmation fonctionnelle telle que C #, vous pouvez écrire du code fonctionnel si vous comprenez les principes FP, de même que vous pouvez appliquer les principes OOP à l'aide de F # si vous comprenez OOP principes, modèles et meilleures pratiques. 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 utilisé.