函数式编程消除了对面向对象设计模式的需求这一说法是否属实?

函数式编程与面向对象编程不同。面向对象的设计模式不适用于函数式编程。取而代之的是函数式编程设计模式。

对于函数式编程，您不需要阅读面向对象设计模式书籍;你会读到其他关于FP设计模式的书籍。

语言无关的

不完全。对于面向对象语言，只有语言不可知。这种设计模式根本不适用于过程式语言。它们在关系数据库设计上下文中几乎没有意义。它们不适用于设计电子表格。

一个典型的OOP设计模式和它的功能对等物?

上述情况不应该存在。这就像要求将一段过程代码重写为OO代码。嗯……如果我将原始的Fortran(或C)翻译成Java，我所做的只是翻译它。如果我完全将其重写为面向对象范式，它将不再看起来像原始的Fortran或C语言——它将无法识别。

从面向对象设计到功能设计没有简单的映射。他们看问题的方式完全不同。

函数式编程(像所有编程风格一样)具有设计模式。关系数据库有设计模式，OO有设计模式，过程式编程有设计模式。任何事物都有设计模式，甚至是建筑物的结构。

设计模式——作为一个概念——是一种永恒的构建方式，与技术或问题领域无关。但是，特定的设计模式适用于特定的问题领域和技术。

每个人只要仔细思考自己在做什么，就会发现设计模式。

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

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

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

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

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

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

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

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

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.

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

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

从本质上说,是的!

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

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