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

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

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

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

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

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

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

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

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

OOP和FP有不同的目标。OOP旨在封装软件组件的复杂/可移动部分，FP旨在最小化软件组件的复杂性和依赖性。

然而，这两种范式并不一定是100%矛盾的，可以一起应用，从两个世界中获得好处。

即使使用像c#这样原生不支持函数式编程的语言，如果您理解FP原则，您也可以编写函数式代码。同样地，如果你理解OOP原则、模式和最佳实践，你也可以使用f#应用OOP原则。无论您使用何种编程语言，您都可以根据您试图解决的情况和问题做出正确的选择。

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

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

甚至OO设计模式解决方案也是特定于语言的。

设计模式是编程语言无法解决的常见问题的解决方案。在Java中，单例模式解决单一的(简化的)问题。

在Scala中，除了Class，还有一个顶级的构造，叫做Object。它是惰性实例化的，只有一个。你不必使用单例模式来获得一个单例。这是语言的一部分。

在函数式编程中，设计模式有不同的含义。事实上，大多数OOP设计模式在函数式编程中都是不必要的，因为有更高层次的抽象和hof用作构建块。

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