有些模式更容易在支持FP的语言中实现。例如，策略可以很好地使用闭包来实现。然而，根据上下文，您可能更喜欢使用基于类的方法来实现策略，例如策略本身非常复杂和/或共享您想使用模板方法建模的结构。

根据我在多范式语言(Ruby)中开发的经验，FP实现在简单的情况下工作得很好，但是在上下文更复杂的情况下，基于GoF OOP的方法更适合。

FP方法并没有取代OOP方法，而是对其进行了补充。

GoF这本书明确地将自己与面向对象绑定在一起——书名是《设计模式——可重用面向对象软件的元素》(重点是我的)。

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

正如其他人所说，函数式编程有特定的模式。我认为摆脱设计模式的问题与其说是转换到功能的问题，不如说是语言特性的问题。

看看Scala是如何废除“单例模式”的:只需声明一个对象而不是一个类。 另一个特性，模式匹配，有助于避免笨重的访问者模式。对比如下: Scala的模式匹配=类固醇访问者模式

Scala和f#一样，是OO-functional的融合。我不了解f#，但它可能有这些特性。

闭包是在函数式语言中出现的，但不需要被限制在函数式语言中。它们有助于使用委托模式。

还有一个观察结果。这段代码实现了一个模式:它是如此经典，如此基本，以至于我们通常不认为它是一个“模式”，但它确实是:

for(int i = 0; i < myList.size(); i++) { doWhatever(myList.get(i)); }

像Java和c#这样的命令式语言已经采用了本质上是一个函数结构来处理这个问题:“foreach”。

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

有些模式更容易在支持FP的语言中实现。例如，策略可以很好地使用闭包来实现。然而，根据上下文，您可能更喜欢使用基于类的方法来实现策略，例如策略本身非常复杂和/或共享您想使用模板方法建模的结构。

根据我在多范式语言(Ruby)中开发的经验，FP实现在简单的情况下工作得很好，但是在上下文更复杂的情况下，基于GoF OOP的方法更适合。

FP方法并没有取代OOP方法，而是对其进行了补充。