我认为只有两个GoF设计模式是用来将函数式编程逻辑引入自然的面向对象语言的。我想到了《战略与指挥》。 其他一些GoF设计模式可以通过函数式编程进行修改，以简化设计并保持目的。

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

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.

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

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

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

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

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

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

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

从本质上说,是的!

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

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

函数式编程不能取代设计模式。设计模式是不可替代的。

模式就是存在的;它们是随着时间的推移而出现的。GoF的书将其中一些正规化了。如果随着开发人员使用函数式编程语言而出现新的模式，那将是令人兴奋的事情，也许也会有关于它们的书籍。