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

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

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

Norvig的演示暗示了他们对所有GoF模式的分析，他们说23个模式中有16个在函数式语言中有更简单的实现，或者只是语言的一部分。因此，大概至少有7个要么是a)同样复杂，要么是b)没有出现在语言中。不幸的是，我们没有列举它们!

我认为很明显，GoF中的大多数“创造性”或“结构性”模式只是让Java或c++中的原始类型系统做你想做的事情的技巧。但是不管你用什么语言编程，其余的都是值得考虑的。

一个可能是Prototype;虽然它是JavaScript的基本概念，但它必须在其他语言中从头开始实现。

我最喜欢的模式之一是空对象模式:表示一个对象不做任何适当的事情。这可能更容易在函数式语言中建模。然而，真正的成就是视角的转变。

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

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

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

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

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

从本质上说,是的!

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

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

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

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

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