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

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

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

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

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

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

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

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

让我们举一个你所陈述的错误前提的例子。

我们在OOP中作为用例适配器(如cleanarch和ddd)的适配器模式可以通过Option的单变量在Functional中实现。

你不是在取代他们，而是在改造他们。

布莱恩关于语言和模式之间紧密联系的评论很中肯，

The missing part of this discussion is the concept of idiom. James O. Coplien's book, "Advanced C++" was a huge influence here. Long before he discovered Christopher Alexander and the Column Without a Name (and you can't talk sensibly about patterns without reading Alexander either), he talked about the importance of mastering idioms in truly learning a language. He used string copy in C as an example, while(*from++ = *to++); You can see this as a bandaid for a missing language feature (or library feature), but what really matters about it is that it's a larger unit of thought, or of expression, than any of its parts.

这就是模式和语言试图做的，让我们更简洁地表达我们的意图。思想的单位越丰富，你能表达的思想就越复杂。从系统架构到琐碎小事，在不同的范围内拥有丰富的、共享的词汇，可以让我们进行更明智的对话，并思考我们应该做什么。

作为个体，我们也可以学习。这就是练习的意义所在。我们每个人都能理解和使用我们自己永远无法想到的东西。语言、框架、库、模式、习语等等都在共享知识财富中占有一席之地。

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

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

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