1024 votes

Ne Programmation Fonctionnelle Remplacer GoF Modèles De Conception?

Depuis que j'ai commencé l'apprentissage de F# et OCaml l'année dernière, j'ai lu un grand nombre d'articles qui insistent pour que les modèles de conception (surtout en Java) sont des solutions de contournement pour les fonctionnalités manquantes dans des langages impératifs. Un article que j'ai trouvé fait une assez forte demande:

La plupart des gens que j'ai rencontrés ont lu l' Modèles de conception de livre par le Gang de Quatre. Tout programmeur qui se respecte vous dire que le livre est langue agnostique et les modèles appliquer pour le génie logiciel général, quelle que soit la langue que vous utilisez. C'est une noble réclamation. Malheureusement, il est loin de la vérité.

Les langages fonctionnels sont extrêmement expressif. Dans un langage fonctionnel on n'a pas besoin de modèles de conception parce que la langue est probable si haut niveau, vous vous retrouvez dans la programmation les concepts qui permettent d'éliminer de la conception modèles tous ensemble.

Les principales caractéristiques de la programmation fonctionnelle inclure des fonctions comme des valeurs de première classe, de nourrissage, des valeurs inaltérables, etc. Il ne semble pas évident pour moi OO modèles de conception sont le rapprochement de ces fonctionnalités.

En outre, dans les langages fonctionnels qui soutiennent la programmation orientée objet (par exemple F# et OCaml), il me semble évident que les programmeurs qui utilisent ces langues utilisent la même conception de modèles disponibles pour tous les autres de la programmation orientée objet du langage. En fait, pour l'instant, j'utilise F# et OCaml tous les jours, et il n'y a pas de grandes différences entre les modèles que j'utilise dans ces langues vs les modèles que j'utilise quand j'écris en Java.

Est-il une vérité dans l'affirmation que la programmation fonctionnelle élimine le besoin pour la programmation orientée objet patrons de conception? Si oui, pourriez-vous poster ou un lien vers un exemple type de la programmation orientée objet, design pattern et de son équivalent fonctionnel?

1046voto

jalf Points 142628

Le blog que vous avez cité exagère sa demande un peu. FP n'est pas d'éliminer la nécessité pour les modèles de conception. Le terme "design patterns" n'est pas largement utilisé pour décrire la même chose dans la FP langues. Mais ils existent. Les langages fonctionnels ont beaucoup de règles de bonne pratique de la forme", lorsque vous rencontrez un problème X, utilisez le code qui ressemble Y", qui est essentiellement ce qu'un modèle de conception est.

Cependant, il est exact que la plupart de la programmation orientée objet-design patterns spécifiques sont un peu hors de propos dans les langages fonctionnels.

Je ne pense pas qu'il devrait être l'objet de controverses-à-dire que les modèles de conception en général n'existent qu'à combler les lacunes dans la langue. Et si une autre langue permet de résoudre le problème de façon triviale, que les autres langues n'aurez pas besoin d'un modèle de conception. Les utilisateurs de cette langue peut même ne pas être conscients que le problème existe, parce que, eh bien, ce n'est pas un problème dans cette langue.

Les principales caractéristiques de la fonctionnelle de programmation comprennent des fonctions comme des valeurs de première classe, de nourrissage, des valeurs inaltérables, etc. Il ne semble pas pour moi évident que les modèles de conception OO sont les rapprochant l'un de ceux les fonctionnalités.

Quel est le modèle de commande, si ce n'est qu'une approximation de première classe de fonctions? :) Dans une langue FP, il vous suffit de passer une fonction comme argument d'une autre fonction. Dans un langage de programmation orientée objet, vous devez envelopper la fonction dans une classe, vous pouvez instancier et de passer ensuite que l'objet de l'autre fonction. L'effet est le même, mais en programmation orientée objet, il est appelé un modèle de conception, et il prend beaucoup plus de code. Et qu'est-ce que le résumé de l'usine modèle, si ce n'est lancer? Passer des paramètres à une fonction un peu à la fois, pour configurer ce type de valeur, il crache enfin, lorsque vous l'appelez.

Donc oui, plusieurs GoF modèles de conception sont superflus dans la FP les langues, car plus puissant et plus facile à utiliser que des alternatives existent.

Mais bien sûr, il existe toujours des modèles de conception qui sont pas résolus par la FP langues. Qu'est-ce que le FP équivalent d'un singleton? (En faisant abstraction un instant que les singletons sont généralement un terrible patron pour l'utiliser)

Et cela fonctionne dans les deux sens aussi. Comme je l'ai dit, le PF a ses modèles de conception de trop, les gens ne peuvent généralement pas de penser à eux en tant que tels.

Mais on peut avoir de courir à travers les monades. Quelles sont-elles, si ce n'est un design pattern pour "traiter avec l'état global"? C'est un problème tout simple en programmation orientée objet, les langages qui n'a d'équivalent modèle de conception.

Nous n'avons pas besoin d'un modèle de conception pour l'incrémentation d'une variable statique", ou "lecture à partir de cette prise", parce que c'est juste ce que vous faites.

Dans (pur), les langages fonctionnels, les effets secondaires et mutable état est impossible, à moins de travailler autour d'elle avec la monade "modèle de conception", ou l'une des autres méthodes pour permettre la même chose.

En outre, dans les langages fonctionnels qui soutiennent la programmation orientée objet (par exemple F# et OCaml), il me semble évident que les programmeurs qui utilisent ces langues utiliser le même design patterns trouvé disponible vers toutes les autres de la programmation orientée objet de langue. En fait, pour l'instant, j'utilise F# et OCaml tous les jours, et il n'y a pas des différences frappantes entre les les modèles que j'utilise dans ces langues vs les modèles que j'utilise quand j'écris dans Java.

Peut-être parce que vous pensez toujours impérativement? Beaucoup de gens, après avoir été en contact avec des langages impératifs, toute leur vie, ont un moment difficile de les abandonner cette habitude lorsqu'ils essaient d'un langage fonctionnel. (J'ai vu des drôles, des tentatives de F#, où littéralement chaque fonction était juste une chaîne de 'laisser' états, en gros un peu comme si vous aviez fait un programme en C, et remplacé tous les points-virgules avec "let". :))

Mais une autre possibilité pourrait être que vous n'en avez pas réalisé que vous êtes à la résolution de problèmes trivialement qui nécessiterait des modèles de conception dans un langage de programmation orientée objet.

Lorsque vous utilisez nourrissage, ou de passer une fonction comme argument d'une autre, arrêtez et pensez à comment vous pouvez le faire dans un langage de programmation orientée objet.

Est-il une vérité dans l'affirmation que la programmation fonctionnelle, élimine la besoin pour la programmation orientée objet patrons de conception?

Yep. :) Lorsque vous travaillez dans une langue FP, vous n'avez plus besoin de la programmation orientée objet-design patterns spécifiques. Mais vous avez encore besoin de quelques modèles de conception, comme MVC ou d'autres non-OOP choses spécifiques, et vous avez besoin d'un couple de nouveaux FP-spécifique "design patterns" à la place. Toutes les langues ont leurs défauts, et les modèles de conception sont généralement de la façon dont nous travaillons autour d'eux.

De toute façon, vous trouverez peut-être intéressant d'essayer votre main à "nettoyeur" FP langues, comme ML (mon favori personnel, au moins à des fins d'apprentissage), ou Haskell, où vous n'avez pas la programmation objet d'une béquille à tomber en arrière sur lorsque vous êtes confronté à quelque chose de nouveau.

Edit: Comme prévu, peu de gens opposés à ma définition de patrons de conception "rafistoler des lacunes dans une langue", 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 une langue spécifique. Souvent, ils résolvent des problèmes que seule existe pas dans ce paradigme (Voir les monades de PF, ou le résumé des usines pour la programmation orientée objet). Pourquoi ne pas le résumé de l'usine modèle existe en FP? Parce que le problème qu'il tente de résoudre n'y existent pas. Donc, si un problème existe dans la programmation orientée objet, les langues, ce qui n'existe pas dans FP langues, alors clairement que c'est une lacune de la programmation orientée objet les langues. Le problème peut être résolu, mais votre langue ne pas le faire, mais nécessite un tas de code réutilisable de vous pour le contourner. Idéalement, nous aimerions que notre langage de programmation, par magie, faire tous les problèmes disparaissent. Tout problème est encore là est, en principe, une lacune de la langue. ;)

147voto

S.Lott Points 207588

Est-il une vérité dans l'affirmation que la programmation fonctionnelle élimine le besoin pour la programmation orientée objet patrons de conception?

La programmation fonctionnelle n'est pas la même que la programmation orientée objet. Orientée objet patrons de conception ne s'appliquent pas à la programmation fonctionnelle. Au lieu de cela, vous avez de la programmation fonctionnelle des modèles de conception.

Pour la programmation fonctionnelle, vous ne lisez pas le modèle de conception OO livres, vous pourrez lire d'autres livres sur le FP des modèles de conception.

langue agnostique

Pas totalement. Seulement indépendant de la langue à l'égard de langages à objets. Les modèles de conception ne s'appliquent pas aux langages procéduraux. Ils ont à peine de sens que 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 typique de la programmation orientée objet, design pattern et de son équivalent fonctionnel?

Le ci-dessus ne devrait pas exister. C'est comme demander à un morceau de code de procédure réécrit comme OO code. Ummm... Si je traduis l'original Fortran (ou C) en Java, je n'ai rien fait de plus que de le traduire. Si je suis totalement réécrire dans un paradigme OO, il n'a plus l'air de rien comme l'original Fortran ou C, il sera méconnaissable.

Il n'y a pas de cartographie simple de OO la Conception à la Conception Fonctionnelle. Ils sont très différents de façons de regarder le problème.

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, 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 -- comme un concept-sont un intemporel mode de construction, indépendamment de la technologie ou du domaine du problème. Cependant, design patterns spécifiques s'appliquent à des domaines de problème et de technologies.

Tout le monde qui pense à propos de ce qu'ils font permettront de découvrir les modèles de conception.

39voto

bright Points 856

Le GOF livre explicitement lie lui-même à la programmation orientée objet - le titre est la Conception de Modèles d'Éléments Réutilisables Orientée Objet Logiciel (c'est moi qui souligne.)

33voto

Darius Bacon Points 9741

Les Modèles de conception Dynamique de la Programmation par Peter Norvig a réfléchi couverture de ce thème général, mais sur le "dynamique" langues, au lieu de "fonctionnel" (il y a chevauchement).

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X