自从我去年开始学习f#和OCaml以来,我已经阅读了大量的文章,这些文章坚持认为设计模式(尤其是Java中的)是命令式语言中缺失特性的变通方法。我发现的一篇文章给出了相当有力的主张:

Most people I've met have read the Design Patterns book by the Gang of Four (GoF). Any self respecting programmer will tell you that the book is language agnostic and the patterns apply to software engineering in general, regardless of which language you use. This is a noble claim. Unfortunately it is far removed from the truth. Functional languages are extremely expressive. In a functional language one does not need design patterns because the language is likely so high level, you end up programming in concepts that eliminate design patterns all together.

函数式编程(FP)的主要特性包括函数作为一类值、curry化、不可变值等。在我看来,OO设计模式是否接近这些特性并不明显。

此外,在支持OOP的函数式语言(如f#和OCaml)中,使用这些语言的程序员显然会使用与其他OOP语言相同的设计模式。事实上,现在我每天都在使用f#和OCaml,我在这些语言中使用的模式与我在Java中使用的模式之间没有明显的区别。

函数式编程消除了对面向对象设计模式的需求这一说法是否属实?如果是这样的话,你能发布或链接到一个典型的OOP设计模式的例子及其功能对等物吗?


当前回答

OOP和FP有不同的目标。OOP旨在封装软件组件的复杂/可移动部分,FP旨在最小化软件组件的复杂性和依赖性。

然而,这两种范式并不一定是100%矛盾的,可以一起应用,从两个世界中获得好处。

即使使用像c#这样原生不支持函数式编程的语言,如果您理解FP原则,您也可以编写函数式代码。同样地,如果你理解OOP原则、模式和最佳实践,你也可以使用f#应用OOP原则。无论您使用何种编程语言,您都可以根据您试图解决的情况和问题做出正确的选择。

其他回答

OOP和GoF模式处理状态。OOP对现实进行建模,使代码库尽可能接近现实的给定需求。GoF设计模式是为解决原子现实问题而确定的模式。它们以语义的方式处理状态问题。

因为在真正的函数式编程中不存在状态,所以应用GoF模式没有意义。功能设计模式与GoF设计模式是不同的。与现实相比,每个功能设计模式都是人为的,因为函数是数学的构造,而不是现实。

函数缺乏时间的概念,因为无论当前时间是多少,它们总是返回相同的值,除非时间是函数参数的一部分,这使得处理“未来的请求”非常困难。混合语言混合了这些概念,使得这些语言不是真正的函数式编程语言。

Functional languages are rising only because of one thing: the current natural restrictions of physics. Todays processors are limited in their speed of processing instructions due to physical laws. You see a stagnation in clock frequency but an expansion in processing cores. That's why parallelism of instructions becomes more and more important to increase speed of modern applications. As functional programming by definition has no state and therefore has no side effects it is safe to process functions safely in parallel.

GoF模式并没有过时。它们至少对真实世界的需求建模是必要的。但是如果你使用函数式编程语言,你必须将它们转换成它们的混合等价物。最后,如果使用持久性,就没有机会只编写函数式程序。对于程序的混合元素,仍然需要使用GoF模式。对于任何其他纯功能性的元素,没有必要使用GoF模式,因为没有状态。

因为GoF模式对于真正的函数式编程不是必需的,这并不意味着不应该应用SOLID原则。SOLID原则超越了任何语言范式。

恕我说一句,函数式编程最重要的特点是,你只用表达式来编程——表达式中的表达式,表达式中的表达式,所有的表达式都计算到最后,最终的表达式“计算时使机器变热”。

以我之见,面向对象编程的最重要的特征是,您正在使用具有内部状态的对象进行编程。在纯函数中不能有内部状态——面向对象的编程语言需要语句来实现。(函数式编程中没有语句。)

你是在拿苹果和橘子作比较。面向对象编程的模式不适用于函数编程,因为函数式编程是使用表达式进行编程,而面向对象编程是使用内部状态进行编程。

这是另一个讨论这个话题的链接:http://blog.ezyang.com/2010/05/design-patterns-in-haskel/

在他的博客文章中,Edward用Haskell描述了所有23种原始的GoF模式。

在2013年的新书《函数式编程模式- In Scala and Clojure》中,作者Michael.B。Linn在很多情况下对GoF模式进行了比较和替换,并讨论了较新的功能模式,如“尾递归”、“记忆化”、“惰性序列”等。

这本书在亚马逊上有售。作为一个拥有几十年OO背景的人,我发现这本书内容丰富,令人鼓舞。

当你试着从“设计模式”(一般)和“FP vs . OOP”的层面来看待这个问题时,你会发现答案最多是模糊的。

但是,在这两个轴上深入研究,并考虑特定的设计模式和特定的语言功能,事情就会变得更清楚。

因此,例如,当使用具有代数数据类型和模式匹配、闭包、第一类函数等的语言时,一些特定的模式(如访问者、策略、命令和观察者)肯定会改变或消失。不过,GoF书中的其他一些模式仍然“存在”。

总的来说,我会说,随着时间的推移,特定的模式正在被新的(或正在流行的)语言特性所淘汰。这是语言设计的自然过程;随着语言变得越来越高级,以前只能在书中使用示例来调用的抽象现在成为特定语言特性或库的应用程序。

(顺便说一句:这是我最近写的一篇博客,上面有更多关于FP和设计模式讨论的链接。)