La programmation fonctionnelle remplace-t-elle les modèles de conception du GoF?


1047

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?


18
Vous pouvez consulter l'article de Steve Yegge ( steve-yegge.blogspot.com/2006/03/… )
Ralph

27
"le livre est indépendant du langage et les modèles s'appliquent au génie logiciel en général" - il convient de noter que le livre n'est pas d'accord avec cette affirmation, dans le sens où certaines langues n'ont pas besoin d'exprimer certaines choses comme les modèles de conception: "Nos modèles supposons 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 [...] CLOS dispose de plusieurs méthodes, par exemple, qui réduisent le besoin d'un modèle tel que Visitor (Page 331). " (page 4)
Guildenstern

6
Gardez également à l'esprit que de nombreux modèles de conception ne sont même pas nécessaires dans des langages impératifs de niveau suffisamment élevé.
R. Barzell

3
@ R.Barzell Quels sont ces "langages impératifs de niveau suffisamment élevé"? Merci.
cibercitizen1

5
@ cibercitizen1 langages de type canard avec prise en charge de fonctions d'ordre supérieur et de fonctions anonymes. Ces fonctionnalités fournissent une grande partie de la puissance que de nombreux modèles de conception étaient censés fournir.
R. Barzell

Réponses:


1077

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


73
Les modèles de conception décrivent des solutions générales aux problèmes de base. Mais c'est aussi ce que font les langages de programmation et les plates-formes. Vous utilisez donc des modèles de conception lorsque les langues et les plates-formes que vous utilisez ne suffisent pas.
yfeldblum

135
S.Lott: Ils décrivent des solutions aux problèmes qui existent dans une langue donnée, oui. Il n'y a pas de modèle de conception de commande dans les langages FP, car le problème qu'il tente de résoudre n'existe pas. Ce qui signifie qu'ils résolvent des problèmes que la langue elle-même ne peut pas résoudre. Autrement dit, des lacunes dans la langue
jalf

38
La monade est un concept mathématique, et vous l'étirez avec votre classification. Bien sûr, vous pouvez afficher les fonctions, les monoïdes, les monades, les matrices ou d'autres concepts mathématiques comme des modèles de conception, mais ceux-ci ressemblent davantage à des algorithmes et des structures de données ... concepts fondamentaux, indépendants du langage.
Alexandru Nedelcu

41
Bien sûr, les monades sont un concept mathématique, mais elles sont aussi un modèle. Le "modèle FP" des monades est quelque peu distinct du concept mathématique des monades. Le premier est un modèle utilisé pour contourner certaines "limitations" dans les langages FP purs. Ce dernier est un concept mathématique universel.
jalf

69
Notez que les monades dans Haskell sont utilisées à d'autres fins que l'état mutable, par exemple pour les exceptions, les continuations, les compréhensions de liste, l'analyse, la programmation asynchrone, etc. Mais toutes ces applications de monades pourraient probablement être appelées modèles.
JacquesB

152

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.


12
MVC n'est pas une conception OO. C'est la conception architecturale - ce modèle s'applique assez largement.
S.Lott

1
@Princess: la programmation fonctionnelle n'est pas nécessairement plus simple. Dans votre exemple, oui. Pour d'autres choses, le jury est toujours absent. Mais vous avez supprimé un modèle de conception Java OO et adopté un modèle de conception FP.
S.Lott

1
+1: Je préfère cette réponse à la réponse de Jalf ci-dessus. Bien que certains modèles de conception corrigent des lacunes dans la langue, tous ne le font pas. Par exemple, je dirais à peine que le modèle de conception "Délier le nœud récursif" résout une lacune dans le langage, c'est juste un idiome utile pour desserrer les dépendances.
Jon Harrop

9
Java 8 inclura des fermetures alias des fonctions anonymes alias des expressions lambda. Cela rendra le modèle de conception de commande obsolète pour Java. Ceci est un exemple de lacune linguistique, non? Ils ont ajouté une fonctionnalité manquante et maintenant vous n'avez plus besoin du modèle de conception.
Todd Chaffee

2
+1 pour la dernière phrase. Les modèles de conception sont destinés à simplifier la programmation et à rendre les programmes résultants plus efficaces, à ce qu'ils sont censés faire.
Trieur

46

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.


8
Je vous remercie! c'est de cela qu'il s'agit - des «blocs conceptuels» pour réduire la charge cognitive.
Randall Schulz

Et les monades fonctionnelles appartiennent définitivement à cette discussion.
Greg

@RandallSchulz: les caractéristiques du langage (et leur utilisation idiomatique, bien sûr) s'inscriraient également bien dans la catégorie des "fragments conceptuels pour réduire la charge cognitive".
Roy Tinker

39

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



26

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.


4
L'article ne semble pas vraiment montrer les modèles de conception dans Haskell, mais montre comment Haskell répond à ces besoins sans lesdits modèles.
Fresheyeball

3
@Fresheyball: dépend de votre définition des modèles. Le mappage d'une fonction sur une liste est-il une variante du modèle Visitor? J'ai généralement pensé que la réponse était «oui». Les modèles sont censés aller au-delà d'une syntaxe particulière. La fonction appliquée peut être encapsulée en tant qu'objet ou passée en tant que pointeur de fonction, mais le concept est le même, pour moi. Êtes-vous en désaccord?
srm

20

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


Comment pouvez-vous dire que le modèle de visiteur "disparaît"? Ne passe-t-il pas simplement de "créer une interface Visiteur avec un tas de méthodes de visite" en "utiliser des types d'unions et des correspondances de motifs"?
Gabe

22
Oui, mais cela a changé d'un modèle qui est une idée de conception que vous lisez dans un livre et appliquez à votre code, à "juste du code". Autrement dit, «utiliser les types d'union et la mise en correspondance de modèles» est simplement la façon dont vous codez normalement des éléments dans un tel langage. (Analogie: si aucun langage n'avait de forboucles et qu'ils avaient tous des whileboucles, alors "Pour" pourrait être un modèle d'itération. Mais quand forest juste une construction supportée par le langage et comment les gens codent normalement, alors ce n'est pas un modèle - vous ne t besoin d'un modèle, c'est juste du code, mec.)
Brian

4
Autrement dit, un test décisif peut-être pas mal pour "est-ce un modèle" est: présent code écrit de cette façon à un étudiant de deuxième année de premier cycle se spécialisant en CS avec un an d'expérience de programmation dans votre langue. Si vous leur montrez le code et qu'ils disent "c'est une conception intelligente", alors c'est un modèle. Si vous leur montrez le code, et qu'ils vont "bien, duh!", Alors ce n'est pas un modèle. (Et si vous montrez ce "Visiteur" à tous ceux qui ont fait du ML / F # / Haskell pendant un an, ils iront "bien, duh!")
Brian

1
Brian: Je pense que nous avons juste différentes définitions d'un "modèle". Je considère que toute abstraction de conception identifiable est un modèle , tandis que vous ne considérez que les abstractions non évidentes comme un modèle . Le fait que C # possède foreachet Haskell mapMne signifie pas qu'ils n'ont pas le modèle Iterator. Je ne vois aucun problème à dire que le modèle Iterator est implémenté en tant IEnumerable<T>qu'interface générique en C # et classe Traversablede types en Haskell.
Gabe

Il se peut que les modèles non évidents soient utiles aux ingénieurs logiciels, mais tous les modèles sont utiles aux concepteurs de langage. C'est-à-dire "Si vous créez une nouvelle langue, assurez-vous d'inclure une manière propre d'exprimer le modèle d'itérateur." Même les modèles évidents sont intéressants lorsque nous commençons à poser la question: «Existe-t-il une meilleure syntaxe pour exprimer cette idée? Après tout, c'est ce qui a amené quelqu'un à créer foreach.
srm

16

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.


2
Quelle analyse étrange à faire depuis que les modèles GoF ont été spécifiquement conçus pour les langages OOP basés sur les classes. Cela ressemble un peu à analyser si les clés à tube sont bonnes pour faire des travaux électriques.
munificent

@munificent: Pas vraiment. L'orientation objet fournit le polymorphisme; la programmation fonctionnelle fournit généralement le polymorphisme.
Marcin

@Marcin un programmeur OO signifie quelque chose de très différent par polymorphisme qu'un programmeur fonctionnel.
AndrewC

@AndrewC Je ne suis pas d'accord. Le programmeur OO peut penser qu'ils signifient quelque chose de différent, mais ils ne le font pas.
Marcin

3
@Marcin D'après mon expérience, un programmeur OO fait généralement référence au polymorphisme de sous-type (souvent en utilisant simplement Object), en utilisant des transtypages pour y parvenir, ou du polymorphisme ad hoc (surcharge, etc.). Quand un programmeur fonctionnel dit polymorphisme, cela signifie polymorphisme paramétrique (c'est-à-dire qu'il fonctionne pour tout type de données - Int, fonction, liste), ce qui ressemble peut-être plus à la programmation générique d'OO qu'à ce que les programmeurs OO appellent habituellement le polymorphisme.
AndrewC

15

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.


Je suis complètement perdu. Pour monter quelque chose avec des abstractions ... Qu'est-ce que cela signifie?
tuinstoel

2
Vous pouvez créer des abstractions spécifiques au domaine (même celles intégrées) sans macros. Les macros vous permettent simplement de les embellir en ajoutant une syntaxe personnalisée.
Jon Harrop

2
Vous pouvez considérer Lisp comme un ensemble de Legos pour construire des langages de programmation - c'est un langage mais c'est aussi un métalangage. Ce qui signifie que pour tout domaine problématique, vous pouvez concevoir sur mesure un langage qui ne présente aucune lacune évidente. Cela demandera un peu de pratique, et Kurt Gödel peut ne pas être d'accord, mais cela vaut la peine de passer du temps avec Lisp pour voir ce qu'il apporte à la table (indice, macros).
Greg

9

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.


8

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


4
Les modèles GoP sont des moyens de résoudre le problème des limitations d'un type particulier de langage de programmation qui vous gênent. Par exemple, "Je veux indirectement sur les classes et leur dire de créer des objets" -> "Vous ne pouvez pas, mais vous pouvez créer des objets de type métaclasse appelés Factory". "Je veux plusieurs envois" -> "Vous ne pouvez pas, mais il y a un labyrinthe que vous pouvez implémenter appelé le modèle de visiteur". Etc. Aucun des motifs n'a de sens si vous n'êtes pas dans un langage OOP avec des limitations spécifiques.
Kaz

1
Je ne sais pas si «aucun» n'a de sens dans d'autres langues, mais je conviens que beaucoup d'entre eux n'ont pas de sens dans d'autres langues. L'adaptateur et le pont semblent avoir plus de possibilités multilingues, diminuant un peu pour le visiteur, et peut-être un peu moins pour l'auditeur. Cependant, les schémas à travers les langues vont toujours souffrir du type "comment faire le fonctionnement de la langue X dans la langue Y" qui étaye les frontières naturelles de la langue. Un exemple parfait était le modèle Singleton, qui est fondamentalement, comment puis-je obtenir des globaux C en POO? (auquel je répondrai, vous ne devriez pas).
Edwin Buck

1
J'appuie Kaz: les schémas ne sont pas "une manière de résoudre des problèmes similaires qui se voient encore et encore" mais "une manière de résoudre des problèmes similaires qui se voient encore et encore ET doivent être réécrits encore et encore parce que la langue ne permet pas ne l'écrire qu'une seule fois ". En d'autres termes, si le langage permettait d'extraire / d'extraire le modèle dans la bibliothèque / classe / module, etc., il cesse d'être un modèle mais devient une bibliothèque / classe / module. Dans FP, il est beaucoup plus facile d'extraire un bit de code abstrait d'une fonction, donc les "motifs" sont plus facilement convertis en code réutilisable, ce qui en fait pas un motif.
mb14

1
Votre interprétation est la bienvenue, mais le livre du GoF était clair pour définir un modèle, et si vous lisez les chapitres d'introduction, il ne dit rien sur les langues ou les faiblesses de la langue. Certes, certaines langues ont des zones qui leur permettront de tirer parti de certains modèles plus souvent, mais que vous l'écriviez dix fois (couper et coller) ou l'implémenter une fois avec dix réalisations (sous-classification), ou avoir un cadre configuré pour le faire dix légèrement différentes manières, n'est qu'un détail de mise en œuvre du motif exposé.
Edwin Buck

1
En revenant dans cette conversation après des années, je pense que beaucoup de gens associent Patterns à un langage de programmation spécifique ou à un paradigme de programmation spécifique. Ils peuvent être utilisés dans un tel contexte, mais ils existaient avant la programmation. «Une façon intemporelle de construire» discute des modèles dans l'architecture du bâtiment et la planification communautaire. Cela implique que les techniques orientées modèle peuvent être utilisées en dehors des "limitations d'un langage" à moins que vous ne vouliez appeler la construction de bâtiments un langage de programmation :)
Edwin Buck

8

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


Je dirais que Scala inclut un support de première classe pour le modèle singleton. Le modèle est toujours là, mais le code passe-partout nécessaire pour appliquer le modèle est considérablement réduit par rapport à Java.
JacquesB

Si les opinions étaient comme un *******, eh bien ... Regardez le reste des réponses. "vous déclarez simplement un objet au lieu d'une classe" est si vrai, je l'appellerais explicitement un objet littéral cependant (ie var singleton = {};). J'aime aussi la mention du modèle foreach. Malheureusement, il semble que la plupart des personnes qui ont répondu / commenté à cette question ne comprennent pas la programmation fonctionnelle et préfèrent justifier l'utilisation des modèles de conception POO. +1 pour fournir des exemples concrets, je donnerais plus si je pouvais.
Evan Plaice

@JacquesB Je ne peux pas commenter Scala / Haskell mais en JavaScript (c'est-à-dire hybride fonctionnel / impératif) il n'y a absolument aucun passe-partout vous ajustez simplement la façon dont vous déclarez les objets en utilisant des combinaisons de syntaxe littérale d'objet, des fonctions anonymes, en passant les fonctions en premier les membres de la classe et permettant l'héritage multiple (éliminant le besoin de contrats d'interface).
Evan Plaice

8

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.


2
"Les modèles de conception du GoF codent des recettes de contournement" est tout simplement une fausse déclaration.
John Peters

7

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


6

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.


6
Comment les classes de types (l'équivalent FP des interfaces OOP) éliminent-elles le besoin de singletons (l'équivalent FP de l'état global)?
Gabe

4

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.


4
Le fait est que le point principal de nombreux modèles est d'exploiter le polymorphisme pour faire des choses que le support décent des concepts de PF pourrait permettre automatiquement. (La plupart des incarnations que j'ai vues de Builder, par exemple, ne sont que du curry à demi-culs.) Une fois que vous pouvez facilement traiter les fonctions comme des valeurs, les modèles se simplifient souvent au point d'être triviaux. Ils deviennent «passer un rappel» ou «avoir un dictionnaire de rappels» - et différentes classes de générateur, par exemple, peuvent presque disparaître. Un modèle OMI cesse d'être un modèle une fois qu'il est assez trivial pour être juste comment les choses fonctionnent , plutôt que quelque chose que vous devez mettre en œuvre.
cHao

4

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.


3

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.


1
Les modèles de conception ne peuvent pas être remplacés? Je pense que c'est un peu fermé d'esprit. Nous pouvons probablement tous convenir que les modèles de conception sont destinés à résoudre des problèmes de programmation, et j'aimerais au moins espérer qu'un jour nous pourrons résoudre ces problèmes sans modèles de conception.
Metropolis

3
Tout modèle particulier peut être remplaçable, mais le concept de modèle ne le peut pas. N'oubliez pas que le terme «modèle» est apparu dans le domaine de l' architecture .
Frank Shearar

1
Les modèles ne sont pas destinés à résoudre des problèmes de programmation. Les modèles sont des moyens que nous programmons. La documentation des modèles est destinée à aider à résoudre les problèmes de programmation.
Torbjørn

3
@ Torbjørn: Les modèles sont des moyens que nous programmons lorsque la langue fait obstacle . Ils existent en raison d'un certain décalage entre le comportement souhaité du programme et les capacités intégrées du langage, où les exigences et les capacités ne correspondent pas bien ou ne sont pas ambiguës. Sans cela, il n'y aurait pas de modèle; vous auriez une implémentation qui est juste la façon dont les choses sont faites , et d'autres implémentations ne seraient effectivement pas utiles.
cHao

1
Sauf que les modèles n'existent vraiment que pour faciliter la communication. Il n'y a pas d'autre but. Et dans toutes les réunions de conception auxquelles j'ai assisté au fil des ans, une discussion sur l' algorithme est ce qui était important, pas sur le modèle. Le schéma expliquait rarement ce qui se passait vraiment dans un sens significatif. Explique-t-il précisément les impacts O (n) vs O (n Log (n))? Non. Cela explique-t-il avec quelle facilité il s'intégrera à l'architecture existante? Les discussions sur les algorithmes à grande échelle le font. Je ne prétends pas que les modèles devraient être retirés en soi, mais s'ils l'étaient, presque rien n'en souffrirait.

3

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.


3

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.


2
La PF peut avoir un état - tout simplement aucun état global, partagé ou mutable.
vt5491

2

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.


1

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.

1

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.


1

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.


1

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.


0

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.


Hmm, j'aurais dû remarquer que la question avait onze ans avant de répondre. :-)
Jim Flood

0

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.


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.