自从我去年开始学习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设计模式在函数式编程中都是不必要的,因为有更高层次的抽象和hof用作构建块。

HOF的原理意味着函数可以作为 参数指向其他函数。函数可以返回值。

其他回答

函数式编程消除了对面向对象设计模式的需求这一说法是否属实?

函数式编程与面向对象编程不同。面向对象的设计模式不适用于函数式编程。取而代之的是函数式编程设计模式。

对于函数式编程,您不需要阅读面向对象设计模式书籍;你会读到其他关于FP设计模式的书籍。

语言无关的

不完全。对于面向对象语言,只有语言不可知。这种设计模式根本不适用于过程式语言。它们在关系数据库设计上下文中几乎没有意义。它们不适用于设计电子表格。

一个典型的OOP设计模式和它的功能对等物?

上述情况不应该存在。这就像要求将一段过程代码重写为OO代码。嗯……如果我将原始的Fortran(或C)翻译成Java,我所做的只是翻译它。如果我完全将其重写为面向对象范式,它将不再看起来像原始的Fortran或C语言——它将无法识别。

从面向对象设计到功能设计没有简单的映射。他们看问题的方式完全不同。

函数式编程(像所有编程风格一样)具有设计模式。关系数据库有设计模式,OO有设计模式,过程式编程有设计模式。任何事物都有设计模式,甚至是建筑物的结构。

设计模式——作为一个概念——是一种永恒的构建方式,与技术或问题领域无关。但是,特定的设计模式适用于特定的问题领域和技术。

每个人只要仔细思考自己在做什么,就会发现设计模式。

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原则超越了任何语言范式。

确实如此,因为高级函数式PL(如OCaml,带有类、模块等)在类型多功能性和表达能力方面肯定会取代OOP命令式语言。抽象不会泄露,你可以在程序中直接表达你的大部分想法。因此,是的,它确实取代了设计模式,无论如何,与功能模式相比,大多数设计模式都简单得可笑。

让我们举一个你所陈述的错误前提的例子。

我们在OOP中作为用例适配器(如cleanarch和ddd)的适配器模式可以通过Option的单变量在Functional中实现。

你不是在取代他们,而是在改造他们。

从本质上说,是的!

当一个模式绕过了缺失的特性(高阶函数、流处理……),最终促进了组合。 一遍又一遍地重写模式实现的需要本身可以被视为一种语言气味。

此外,这个页面(AreDesignPatternsMissingLanguageFeatures)提供了一个“模式/功能”转换表和一些不错的讨论,如果你愿意深入研究的话。