La programmation fonctionnelle remplace-t-elle les modèles de conception du 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) sont des solutions de contournement pour les fonctionnalités manquantes dans les langages impératifs. Un article que j'ai trouvé fait une affirmation assez forte :

La plupart des gens que j'ai rencontrés ont lu le livre Design Patterns du Gang of Four (GoF). Tout programmeur qui se respecte vous dira que le livre est indépendant du langage 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, c'est loin de la vérité.

Les langages fonctionnels sont extrêmement expressifs. Dans un langage fonctionnel, on n'a pas besoin de modèles de conception, car le langage est probablement de haut niveau, vous finissez par programmer des concepts qui éliminent tous les modèles de conception.

Les principales caractéristiques de la programmation fonctionnelle (FP) incluent des fonctions comme valeurs de première classe, currying, valeurs immuables, etc. Il ne me semble pas évident que les modèles de conception OO se rapprochent de ces fonctionnalités.

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 tous les autres langages 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 lorsque j'écris en Java.

Existe-t-il une vérité dans l'affirmation selon laquelle la programmation fonctionnelle élimine le besoin de modèles de conception POO? Si oui, pourriez-vous publier ou créer un lien vers un exemple d'un modèle de conception POO typique et son équivalent fonctionnel?

Le blog que vous avez cité exagère un peu sa revendication. FP n'élimine le besoin de modèles de conception. Le terme «modèles de conception» n'est tout simplement pas largement utilisé pour décrire la même chose dans les langages FP. Mais ils existent. Les langages fonctionnels ont 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 sont à peu près non 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 combler les lacunes du langage. Et si une autre langue peut résoudre trivialement le même problème, cette autre langue n'aura pas besoin d'un modèle de conception pour cela. Les utilisateurs de cette langue ne savent peut-être même pas que le problème existe , car ce n'est pas un problème dans cette langue.

Voici ce que le Gang of Four a à dire à ce sujet:

Le choix du langage de programmation est important car il influence son point de 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 supposions des langages procéduraux, nous aurions pu inclure des modèles de conception appelés "héritage", "encapsulation" et "polymorphisme". De même, certains de nos modèles sont pris en charge directement par les langages orientés objet moins courants. CLOS a, par exemple, plusieurs méthodes qui réduisent le besoin d'un modèle tel que Visitor. En fait, il y a 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 Iterator 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 comprennent des fonctions comme valeurs de première classe, curry, 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 des fonctions de première classe? :) Dans un langage FP, vous passeriez simplement une fonction comme argument à une autre fonction. Dans un langage OOP, vous devez encapsuler la fonction dans une classe, que vous pouvez instancier puis transmettre cet objet à l'autre fonction. L'effet est le même, mais dans la POO, cela s'appelle un modèle de conception, et cela prend beaucoup plus de code. Et quel est le modèle d'usine abstrait, sinon curry? Passez les paramètres à une fonction un peu à la fois, pour configurer le type de valeur qu'elle crache lorsque vous l'appelez finalement.

Alors oui, plusieurs modèles de conception GoF sont rendus redondants dans les langages FP, 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 les langages FP. Quel est l'équivalent FP d'un singleton? (Ignorant un instant que les singletons sont généralement un modèle terrible à utiliser.)

Et cela fonctionne 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 traversé des monades. Quels sont-ils, sinon un modèle de conception pour "faire face à l'état global"? C'est un problème si simple dans les langages POO qu'aucun modèle de conception équivalent n'existe là-bas.

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 qu'une monade est un modèle de conception est aussi absurde que de dire les entiers avec leurs opérations habituelles et l'élément zéro est un modèle de conception. Non, une monade est un modèle mathématique , pas un modèle de conception.

Dans les langages fonctionnels (purs), les effets secondaires et l'état mutable sont impossibles, à moins que vous ne les contourniez avec le «modèle de conception» monade, ou l'une des autres méthodes permettant 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 tous les autres langages 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 lorsque j'écris en Java.

Peut-être parce que vous pensez encore impérativement? Beaucoup de gens, après avoir traité des langues impératives toute leur vie, ont du mal à abandonner cette habitude lorsqu'ils essaient un langage fonctionnel. (J'ai vu quelques tentatives assez drôles de F #, où littéralement chaque fonction n'était qu'une chaîne d'instructions «let», essentiellement comme si vous aviez pris un programme C et remplacé tous les points-virgules par «let». :))

Mais une autre possibilité pourrait être que vous n'avez tout simplement pas réalisé que vous résolvez des problèmes de manière triviale, ce qui nécessiterait des modèles de conception dans un langage OOP.

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

Existe-t-il une vérité dans l'affirmation selon laquelle la programmation fonctionnelle élimine le besoin de modèles de conception 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 plutôt besoin de quelques nouveaux "modèles de conception" spécifiques à FP. Toutes les langues ont leurs défauts, et les modèles de conception sont généralement la façon dont nous travaillons autour d'eux.

Quoi qu'il en soit, vous trouverez peut-être intéressant de vous essayer à des langages de FP "plus propres", comme ML (mon préféré, au moins à des fins d'apprentissage), ou Haskell , où vous n'avez pas la béquille OOP pour vous rabattre lorsque vous suis confronté à quelque chose de nouveau.

Comme prévu, quelques personnes se sont opposées à ma définition des modèles de conception comme "corriger les lacunes dans un langage", voici donc ma justification:

Comme déjà dit, la plupart des modèles de conception sont spécifiques à un paradigme de programmation, ou parfois même à 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 abstrait 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 les langues OOP, qui n'existe pas dans les langues FP, alors clairement c'est une lacune des langues OOP. Le problème peut être résolu, mais votre langue ne le fait pas, mais nécessite un tas de code standard pour contourner ce problème. Idéalement, nous aimerions que notre langage de programmation élimine comme par magie tous les problèmes. Tout problème qui persiste est en principe une lacune de la langue. ;)

Existe-t-il une vérité dans l'affirmation selon laquelle la programmation fonctionnelle élimine le besoin de modèles de conception POO?

La programmation fonctionnelle n'est pas la même chose 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 disposez de modèles de conception de programmation fonctionnelle.

Pour la 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. Uniquement indépendant de la langue par rapport aux langues OO. Les modèles de conception ne s'appliquent pas du tout aux langages procéduraux. Ils n'ont guère de sens dans un contexte de conception de base de données relationnelle. Ils ne s'appliquent pas lors de la conception d'une feuille de calcul.

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 procédural réécrit en code OO. Ummm ... Si je traduis le Fortran (ou C) original 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 d'origine - il sera méconnaissable.

Il n'y a pas de mappage simple de la conception OO à la conception fonctionnelle. Ce sont des façons très différentes d'aborder le problème.

La programmation fonctionnelle (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 et la programmation procédurale a des modèles de conception. Tout a des motifs 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 technologies de problème 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 au point,

La partie manquante de cette discussion est le concept d'idiome. Le livre de James O. 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 non plus parler de motifs de manière judicieuse sans lire Alexander), il a parlé de l'importance de maîtriser les idiomes pour vraiment apprendre une langue. Il a utilisé la copie de chaîne en C comme exemple, while(*from++ = *to++);vous pouvez le voir comme un bandaid pour une fonctionnalité de langue manquante (ou une fonctionnalité de bibliothèque), mais ce qui compte vraiment, c'est que c'est une plus grande unité de pensée ou d'expression que n'importe laquelle 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 du système au twiddling - nous permet d'avoir des conversations plus intelligentes et des réflexions sur ce que nous devrions faire.

Nous pouvons également, en tant qu'individus, apprendre. C'est tout l'intérêt de l'exercice. Nous pouvons chacun comprendre et utiliser des choses auxquelles nous ne pourrions jamais penser. Les langues, les cadres, les bibliothèques, les modèles, les idiomes, etc. ont tous leur place dans le partage de la richesse intellectuelle.

Le livre du GoF se lie explicitement à la POO - le titre est Design Patterns - Elements of Reusable Object-Oriented Software (c'est moi qui souligne).

Design Patterns in Dynamic Programming par Peter Norvig a une couverture réfléchie de ce thème général, bien que sur les langages «dynamiques» au lieu de «fonctionnels» (il y a chevauchement).

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

Dans son article de blog, 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 "FP versus OOP", les réponses que vous trouverez seront au mieux floues.

Allez plus loin 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, comme Visitor , Strategy , Command et Observer, changent ou disparaissent définitivement lors de l'utilisation d'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. Certains autres modèles du livre du GoF sont toujours «rester», cependant.

En général, je dirais qu'au fil du temps, des modèles spécifiques sont éliminés par de nouvelles fonctionnalités linguistiques (ou simplement en hausse de popularité). C'est le cours naturel de la conception du langage; au fur et à mesure que les langues deviennent plus avancées, les abstractions qui ne pouvaient auparavant être énoncées que dans un livre à l'aide d'exemples deviennent désormais des applications d'une fonctionnalité ou d'une bibliothèque de langage particulière.

(En plus: voici un blog récent que j'ai écrit, qui a d'autres liens vers plus de discussion sur les modèles de FP et de conception.)

La présentation de Norvig fait allusion à une analyse qu'ils ont faite de tous les modèles du 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. Il est donc probable qu'au moins sept d'entre eux étaient a) tout aussi compliqués ou 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" dans GoF ne sont que des astuces pour que les systèmes de type primitif en Java ou C ++ fassent ce que vous voulez. Mais le reste mérite d'être pris en considération, quelle que soit la langue dans laquelle vous programmez.

L'un pourrait être le prototype; bien qu'il s'agisse d'une notion fondamentale de JavaScript, il doit être implémenté à partir de zéro dans d'autres langues.

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 qui ne fait rien de bon. Cela peut être plus facile à modéliser dans un langage fonctionnel. Cependant, la véritable réussite 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 au domaine, des abstractions qui sont souvent bien meilleures que les solutions idiomatiques générales.

Et même les solutions de modèle de conception OO 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é).

Dans Scala, vous disposez d'une construction de niveau supérieur appelée Object en plus de Class. Il 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.

Les modèles sont des moyens de résoudre des problèmes similaires qui sont vus encore et encore, puis décrits et documentés. Donc non, FP ne remplacera pas les modèles; cependant, FP peut créer de nouveaux modèles et rendre certains modèles de "meilleures pratiques" actuels "obsolètes".

Comme d'autres l'ont dit, il existe des modèles spécifiques à la programmation fonctionnelle. Je pense que la question de se débarrasser des modèles de conception n'est pas tant une question de passage au fonctionnel, mais une question de fonctionnalités de langage .

Jetez un œil à la façon dont Scala supprime le "motif singleton": vous déclarez simplement un objet au lieu d'une classe. Une autre caractéristique, la correspondance de motifs, permet d'éviter l'encombrement du motif visiteur. Voir la comparaison ici: Scala's Pattern Matching = Pattern visiteur sur les stéroïdes

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

Les fermetures sont présentes dans le langage fonctionnel, mais elles ne doivent pas être limitées à elles. Ils aident avec le modèle de délégation.

Encore une observation. Ce morceau de code implémente un modèle: c'est un tel classique et il est tellement élémentaire que nous ne le considérons généralement pas comme un "modèle", mais il est sûr:

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 gérer cela: "foreach".

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

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

• des classes typées statiquement, qui spécifient des objets, mais ne sont pas elles-mêmes des objets;
• restriction à la répartition unique (seul l'argument le plus à gauche est utilisé pour sélectionner une méthode, les arguments restants sont considérés uniquement comme des types statiques: s'ils ont des types dynamiques, c'est à la méthode de trier cela avec des approches ad hoc);
• distinction entre les appels de fonction réguliers et les appels de fonction orientés objet, ce qui signifie que les fonctions orientées objet ne peuvent pas être passées comme arguments fonctionnels lorsque des fonctions régulières sont attendues et vice versa; et
• distinction entre "types de base" et "types de classe".

Il n'y a pas un seul de ces modèles de conception qui ne disparaisse pas dans le système d'objets 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. (De plus, ce système d'objets précède le livre du GoF de bien plus d'une décennie. Common Lisp est devenu un standard ANSI la même année que ce livre a été publié pour la première fois.)

En ce qui concerne la programmation fonctionnelle, l'applicabilité ou non des modèles dépend du fait que le langage de programmation fonctionnel donné possède une sorte de système d'objets et s'il est modélisé d'après les systèmes d'objets qui bénéficient des modèles. Ce type d'orientation d'objet ne se mélange pas bien avec la programmation fonctionnelle, car la mutation d'état est à l'avant et au centre.

La construction et l'accès non mutant sont compatibles avec la programmation fonctionnelle, et donc les modèles qui ont à voir avec l'accès abstrait ou la construction pourraient être applicables: des modèles comme Factory, Facade, Proxy, Decorator et Visitor.

D'un autre côté, les schémas comportementaux comme l'État et la stratégie ne s'appliquent probablement pas directement dans la POO fonctionnelle, car la mutation de l'état est au cœur. Cela ne signifie pas qu'ils ne s'appliquent pas; peut-être s'appliquent-ils en quelque sorte en combinaison avec toutes les astuces disponibles pour simuler un état mutable.

Je voudrais brancher quelques articles excellents mais quelque peu denses de Jeremy Gibbons: "Design patterns as high-order datatype-generic programmes" et "The essence of the Iterator pattern" (tous deux disponibles ici: http: // www. comlab.ox.ac.uk/jeremy.gibbons/publications/ ).

Ces deux éléments 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 mettre en place des systèmes de types.

Les principales caractéristiques de la programmation fonctionnelle comprennent des fonctions comme valeurs de première classe, curry, valeurs immuables, etc. Il ne me semble pas évident que les modèles de conception OO se rapprochent de ces caractéristiques.

C'est parce que ces fonctionnalités ne répondent pas aux mêmes problèmes que la POO ... elles sont des alternatives à la programmation impérative. La réponse FP à la POO réside dans les systèmes de types de ML et Haskell ... spécifiquement les types de somme, les types de données abstraits, les modules ML et les classes de 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? (Ignorant 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 davantage, mais je n'ai pas le temps pour l'instant.

Je pense que seulement deux modèles de conception GoF sont conçus pour introduire la logique de programmation fonctionnelle dans le langage OO naturel. Je pense à la stratégie et au commandement. Certains des autres modèles de conception du GoF peuvent être modifiés par une programmation fonctionnelle pour simplifier la conception et conserver l'objectif.

Essentiellement, oui !

• Lorsqu'un motif contourne les fonctionnalités manquantes (fonctions de haut niveau, gestion des flux ...) qui facilitent ultimement la composition .
• La nécessité de réécrire la mise en œuvre des modèles encore et encore peut elle-même être considérée comme une odeur de langage .

En outre, cette page (AreDesignPatternsMissingLanguageFeatures) fournit un tableau de traduction "modèle / fonctionnalité" et quelques discussions intéressantes, si vous êtes prêt à creuser.

La programmation fonctionnelle 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é au fil du temps. Le livre du GoF a officialisé certains d'entre eux. Si de nouveaux modèles apparaissent lorsque les développeurs utilisent des langages de programmation fonctionnels, c'est passionnant, et peut-être qu'il y aura aussi des livres écrits à leur sujet.

Dans le nouveau livre de 2013 intitulé "Functional Programming Patterns - in Scala and Clojure", l'auteur Michael.B. Linn fait un travail décent en comparant et en fournissant des remplacements dans de nombreux cas pour les modèles GoF et discute également des modèles fonctionnels plus récents comme la `` récursivité 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 en venant d'un milieu OO de quelques décennies.

La POO et les modèles du GoF traitent des états. La POO modélise la réalité pour garder la base de code aussi proche que possible des exigences données 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 atomiques du monde réel. Ils traitent le problème de l'Etat de manière sémantique.

Comme dans la vraie programmation fonctionnelle, aucun état n'existe, il n'est pas logique d'appliquer les modèles GoF. 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 la notion de temps car elles renvoient toujours la même valeur quelle que soit l'heure actuelle, sauf si le temps fait partie des paramètres de fonction, ce qui rend très difficile le prétraitement 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 n'augmentent que grâce à une 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 des lois physiques. Vous voyez une stagnation de la fréquence d'horloge mais une expansion des 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. La programmation fonctionnelle n'ayant par définition aucun état et donc aucun effet secondaire, il est sûr de traiter les fonctions en parallèle en toute sécurité.

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 la nécessité d'utiliser des modèles GoF. Pour tout autre élément purement fonctionnel, il n'est pas nécessaire d'utiliser des modèles GoF car il n'y a pas d'état.

Parce que les modèles GoF ne sont pas nécessaires pour une véritable programmation fonctionnelle, cela ne signifie pas que les principes SOLID ne doivent pas être appliqués. Les principes SOLID dépassent tout paradigme linguistique.

Dans la programmation fonctionnelle, les modèles de conception ont une signification différente. En fait, la plupart des modèles de conception OOP ne sont pas nécessaires dans la programmation fonctionnelle en raison du niveau d'abstraction plus élevé et des HOF utilisés comme blocs de construction.

Le principe d'un HOF signifie que les fonctions peuvent être passées comme arguments à d'autres fonctions. et les fonctions peuvent renvoyer des valeurs.

Comme l'a dit la réponse acceptée, la POO et la PF ont toutes leurs schémas spécifiques.

Cependant, il existe certains modèles si communs que toutes les plates-formes de programmation auxquelles je peux penser 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-satisfaite) qu'elle n'a pas besoin de parler au monde. Pour ce faire, un adaptateur est absolument nécessaire.

• Façade. Toutes les plates-formes de programmation capables de gérer un gros code source devraient pouvoir modulariser. Si vous deviez créer un module pour d'autres parties du programme, vous voudrez cacher les parties "sales" du code et lui donner une belle interface.

• Interprète. En général, tout programme ne fait que deux choses: analyser l’entrée et imprimer la sortie. 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.

De plus, j'ai remarqué que dans un langage FP typique, Haskell, il y a quelque chose de similaire aux modèles GoF, mais avec des noms différents. À mon avis, cela suggère qu'ils étaient là parce qu'il y a des problèmes communs à résoudre dans les langues FP et OOP.

• Transformateur et décorateur monade. Les premiers ajoutaient des capacités supplémentaires à une monade existante, les seconds ajoutaient des capacités supplémentaires à un objet existant.

Je pense que chaque paradigme sert un objectif différent et en tant que tel ne peut pas être comparé de cette façon.

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 s'appliquent à toutes les langues de POO . Si vous utilisez une programmation fonctionnelle, 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 n'envisagerais pas d'utiliser des modèles de conception OO.

La POO et la PF ont des objectifs différents. La POO vise à encapsuler les complexités / parties mobiles des composants logiciels et la FP vise à minimiser la complexité et les dépendances des composants logiciels.

Cependant, ces deux paradigmes ne sont pas nécessairement contradictoires à 100% et pourraient être appliqués ensemble pour tirer parti des deux mondes.

Même avec un langage qui ne prend pas en charge nativement la programmation fonctionnelle comme C #, vous pouvez écrire du code fonctionnel si vous comprenez les principes de FP. De même, vous pouvez appliquer les principes de la POO à l'aide de F # si vous comprenez les principes, les modèles et les meilleures pratiques de la POO. Vous feriez le bon choix en fonction de la situation et du problème que vous essayez de résoudre, quel que soit le langage de programmation que vous utilisez.

Certains modèles sont plus faciles à implémenter dans un langage prenant en charge la PF. Par exemple, la stratégie peut être mise en œuvre en utilisant joliment des fermetures. Cependant, selon le contexte, vous préférerez peut-être implémenter la stratégie en utilisant une approche basée sur les classes, par exemple lorsque les stratégies elles-mêmes sont assez compliquées et / ou partagent la structure que vous souhaitez modéliser à l'aide de la méthode de modèle.

D'après mon expérience de développement dans un langage multi-paradigme (Ruby), la mise en œuvre de FP fonctionne bien dans des cas simples, mais lorsque le contexte est plus compliqué, l'approche basée sur la POO du GoF est mieux adaptée.

L'approche PF ne remplace pas l'approche OOP, elle la complète.

La caractéristique primordiale de la programmation fonctionnelle, à mon humble avis, est que vous ne programmez qu'avec des expressions - des expressions dans des expressions dans des expressions qui évaluent toutes jusqu'à la dernière expression finale qui "réchauffe la machine lorsqu'elle est évaluée".

La caractéristique primordiale de la programmation orientée objet, à mon humble avis, c'est que vous programmez avec des objets qui ont un état interne. Vous ne pouvez pas avoir d'état interne dans des fonctions pures - les langages de programmation orientés objet ont besoin d' instructions pour que les choses se produisent. (Il n'y a pas d'instructions dans la programmation fonctionnelle.)

Vous comparez des pommes à des oranges. Les modèles de programmation orientée objet ne s'appliquent pas à la programmation de fonction, car la programmation fonctionnelle est la programmation avec des expressions, et la programmation orientée objet est la programmation avec l'état interne.

Préparez-vous.

Cela va en aggraver beaucoup de m'entendre affirmer avoir remplacé les modèles de conception et démystifié SOLID et DRY. Je ne suis personne. Néanmoins, j'ai correctement modélisé l'architecture collaborative (de fabrication) et publié les règles de construction des processus en ligne ainsi que le code et la science derrière sur mon site Web http://www.powersemantics.com/ .

Mon argument est que les modèles de conception tentent de réaliser ce que la fabrication appelle la "personnalisation de masse", une forme de processus dans laquelle chaque étape peut être remodelée, recomposée et étendue. Vous pourriez penser à de tels processus comme des scripts non compilés. Je ne vais pas répéter mon argument (en ligne) ici. En bref, mon architecture de personnalisation de masse remplace les modèles de conception en atteignant cette flexibilité sans aucune sémantique désordonnée. J'ai été surpris que mon modèle fonctionne si bien, mais la façon dont les programmeurs écrivent du code ne tient tout simplement pas compte de la façon dont la fabrication organise le travail collaboratif.

• Fabrication = chaque étape interagit avec un produit
• POO = chaque étape interagit avec elle-même et avec les autres modules, faisant passer le produit de point en point comme des employés de bureau inutiles

Cette architecture n'a jamais besoin d'être refactorisée. Il existe également des règles concernant la centralisation et la distribution qui affectent la complexité. Mais pour répondre à votre question, la programmation fonctionnelle est un autre ensemble de sémantique de traitement, pas une architecture pour les processus personnalisés de masse où 1) le routage source existe en tant que document (script) que le porteur peut réécrire avant le tir et 2) les modules peuvent être facilement et ajouté ou supprimé dynamiquement.

On pourrait dire que la POO est le paradigme du «processus codé en dur» et que les modèles de conception sont des moyens d'éviter ce paradigme. Mais c'est à cela que sert la personnalisation de masse. Les modèles de conception incarnent des processus dynamiques comme un code dur désordonné. Cela ne sert à rien. Le fait que F # permet de passer des fonctions comme paramètre moyens fonctionnels et POO langues tentative aussi bien pour accomplir lui - même la personnalisation de masse.

À quel point est-ce déroutant pour le lecteur, le code dur qui représente le script? Pas du tout si vous pensez que les consommateurs de votre compilateur paient pour de telles fonctionnalités, mais pour moi, ces fonctionnalités sont des déchets sémantiques. Ils sont inutiles, car le point de personnalisation de masse est de rendre les processus eux-mêmes dynamiques , et pas seulement dynamiques pour le programmeur utilisant Visual Studio.

Il le fait, dans la mesure où un PL fonctionnel de haut niveau (comme OCaml, avec des classes, des modules, etc.) remplace certainement les langages impératifs OOP en termes de polyvalence de type et de puissance d'expression. Les abstractions ne fuient pas, vous pouvez exprimer la plupart de vos idées directement dans le programme. Par conséquent, oui, il remplace les modèles de conception, dont la plupart sont ridiculement simplistes par rapport aux modèles fonctionnels de toute façon.