oop - 函数式编程会取代 GoF 设计模式吗？

Question

自从我开始学习 F#和 OCaml去年，我阅读了大量文章，这些文章坚持认为设计模式(尤其是在 Java 中)是命令式语言中缺失功能的解决方法。我找到的一篇文章 makes a fairly strong claim :

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) 的主要特性包括将函数作为一等值、柯里化、不可变值等。在我看来，OO 设计模式接近于这些特性中的任何一个似乎并不明显。

此外，在支持 OOP 的函数式语言(例如 F# 和 OCaml)中，在我看来很明显，使用这些语言的程序员将使用与其他所有 OOP 语言都可用的相同设计模式。事实上，现在我每天都在使用 F# 和 OCaml，我在这些语言中使用的模式与我用 Java 编写时使用的模式之间没有显着差异。

函数式编程消除了对 OOP 设计模式的需要的说法是否有道理？如果是这样，您能否发布或链接到典型的 OOP 设计模式及其等效功能的示例？

Answer 1

你引用的博客文章夸大了它的主张。 FP 并没有消除对设计模式的需要。术语“设计模式”并未广泛用于描述 FP 语言中的相同事物。但它们存在。函数式语言有很多最佳实践规则，形式为“当你遇到问题 X 时，使用看起来像 Y 的代码”，这基本上就是设计模式。

然而，大多数 OOP 特定的设计模式在函数式语言中几乎无关紧要，这是正确的。

我认为说设计模式一般只是为了弥补语言中的缺点而存在的说法不应该特别有争议。
如果另一种语言可以轻松解决相同的问题，那么这种语言就不需要设计模式了。该语言的用户甚至可能没有意识到问题的存在，因为，这不是该语言的问题。

以下是四人帮对这个问题的看法:

The choice of programming language is important because it influences one's point of view. Our patterns assume Smalltalk/C++-level language features, and that choice determines what can and cannot be implemented easily. If we assumed procedural languages, we might have included design patterns called "Inheritance", "Encapsulation," and "Polymorphism". Similarly, some of our patterns are supported directly by the less common object-oriented languages. CLOS has multi-methods, for example, which lessen the need for a pattern such as Visitor. In fact, there are enough differences between Smalltalk and C++ to mean that some patterns can be expressed more easily in one language than the other. (See Iterator for example.)

(以上引自《设计模式简介》一书，第 4 页，第 3 段)

The main features of functional programming include functions as first-class values, currying, immutable values, etc. It doesn't seem obvious to me that OO design patterns are approximating any of those features.

如果不是一等函数的近似值，命令模式是什么？ :)
在 FP 语言中，您只需将一个函数作为参数传递给另一个函数。
在 OOP 语言中，您必须将函数封装在一个类中，您可以实例化该类，然后将该对象传递给另一个函数。效果是一样的，但在 OOP 中它被称为设计模式，它需要更多的代码。
如果不是柯里化，抽象工厂模式是什么？一次一点地向一个函数传递参数，以配置它在您最终调用它时吐出什么样的值。

所以是的，在 FP 语言中，一些 GoF 设计模式变得多余，因为存在更强大和更易于使用的替代方案。

但是当然还有一些设计模式是 FP 语言没有解决的。什么是单例的 FP 等价物？ (暂时忽略单例通常是一种可怕的模式。)

它也适用于两种方式。正如我所说，FP 也有它的设计模式；人们只是通常不这么认为。

但是您可能遇到过 monad。如果不是“处理全局状态”的设计模式，它们是什么？这是一个在 OOP 语言中非常简单的问题，以至于那里不存在等效的设计模式。

我们不需要“增加静态变量”或“从该套接字读取”的设计模式，因为这正是您所做的。

说 monad 是一种设计模式，就像说带有通常操作的整数和零元素是一种设计模式一样荒谬。不，monad 是 数学模式 ，不是设计模式。

在(纯)函数式语言中，副作用和可变状态是不可能的，除非您使用 monad“设计模式”或任何其他允许相同事情的方法来解决它。

Additionally, in functional languages which support OOP (such as F# and OCaml), it seems obvious to me that programmers using these languages would use the same design patterns found available to every other OOP language. In fact, right now I use F# and OCaml everyday, and there are no striking differences between the patterns I use in these languages vs the patterns I use when I write in Java.

或许是因为你还在急切地思考？很多人在用了一生的命令式语言之后，在尝试函数式语言时很难放弃这种习惯。 (我在 F# 中看到过一些非常有趣的尝试，实际上每个函数都只是一串“let”语句，基本上就像您编写了一个 C 程序，并用“let”替换了所有分号。:))

但另一种可能性可能是您只是没有意识到您正在解决的问题很琐碎，而这需要 OOP 语言中的设计模式。

当你使用柯里化，或者将一个函数作为参数传递给另一个时，停下来想想你将如何在 OOP 语言中做到这一点。

Is there any truth to the claim that functional programming eliminates the need for OOP design patterns?

是的。 :)
当您使用 FP 语言工作时，您不再需要特定于 OOP 的设计模式。但是您仍然需要一些通用设计模式，例如 MVC 或其他非 OOP 特定的东西，并且您需要一些新的特定于 FP 的“设计模式”。所有语言都有其缺点，设计模式通常是我们解决它们的方式。

无论如何，您可能会发现尝试“更干净”的 FP 语言很有趣，例如 ML (我个人最喜欢的，至少用于学习目的)，或 Haskell ，当您面对新事物时，您没有 OOP 拐杖可以依靠。

正如预期的那样，一些人反对我将设计模式定义为“修补语言中的缺点”，所以这是我的理由:

如前所述，大多数设计模式都特定于一种编程范式，有时甚至是一种特定语言。通常，它们解决仅存在于该范式中的问题(参见 FP 的单子(monad)，或 OOP 的抽象工厂)。

为什么FP中不存在抽象工厂模式？因为它试图解决的问题并不存在。

所以，如果 OOP 语言存在问题，而 FP 语言不存在，那么显然这是 OOP 语言的一个缺点。问题可以解决，但您的语言不这样做，而是需要您提供一堆样板代码来解决它。理想情况下，我们希望我们的编程语言能够神奇地解决所有问题。任何仍然存在的问题原则上都是语言的缺点。 ;)