我认为每个范式都有不同的目的，因此不能以这种方式进行比较。

我还没有听说过GoF设计模式适用于每一种语言。我听说它们适用于所有面向对象语言。如果您使用函数式编程，那么您解决的问题领域就不同于OO语言。

我不会使用函数式语言来编写用户界面，但是像c#或Java这样的面向对象语言会使这项工作更容易。如果我正在编写一种函数式语言，那么我就不会考虑使用OO设计模式。

讨论这个问题时不能不提到类型系统。

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

这是因为这些特性不能解决OOP所解决的问题……它们是命令式编程的替代品。面向对象的FP答案在于ML和Haskell的类型系统……特别是和类型、抽象数据类型、ML模块和Haskell类型类。

当然，仍然有一些设计模式是FP语言无法解决的。FP与单例的等价是什么?(暂时不考虑单例对象通常是一种糟糕的模式)

类型类做的第一件事是消除对单例对象的需求。

你可以浏览这23个名单，然后再剔除更多，但我现在没有时间。

我想说的是，当你拥有像Lisp这样支持宏的语言时，你就可以构建你自己的领域特定的抽象，这些抽象通常比一般的习语解决方案要好得多。

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

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

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

正如公认的答案所说，OOP和FP都有其特定的模式。

然而，有一些模式是非常常见的，我能想到的所有编程平台都应该有。以下是一个(不完整的)列表:

Adapter. I can hardly think of a useful programming platform which is so comprehensive (and self-fulfilled) that it does not need to talk to the world. If it is going to do so, an adapter is definitely needed. Façade. Any programming platforms that can handle big source code should be able to modularise. If you were to create a module for other parts of the program, you will want to hide the "dirty" parts of the code and give it a nice interface. Interpreter. In general, any program is just doing two things: parse input and print output. Mouse inputs need to be parsed, and window widgets need to be printed out. Therefore, having an embedded interpreter gives the program additional power to customise things.

另外，我注意到在典型的FP语言Haskell中，有一些类似于GoF模式的东西，但名称不同。在我看来，这表明它们存在，因为在FP和OOP语言中都有一些共同的问题需要解决。

单子转换器和装饰器。前者用于向现有的单子中添加额外的能力，后者用于向现有的对象中添加额外的能力。