确实如此，因为高级函数式PL(如OCaml，带有类、模块等)在类型多功能性和表达能力方面肯定会取代OOP命令式语言。抽象不会泄露，你可以在程序中直接表达你的大部分想法。因此，是的，它确实取代了设计模式，无论如何，与功能模式相比，大多数设计模式都简单得可笑。

讨论这个问题时不能不提到类型系统。

函数式编程的主要特征包括函数作为第一类值、curry化、不可变值等。在我看来，OO设计模式是否接近这些特性并不明显。

这是因为这些特性不能解决OOP所解决的问题……它们是命令式编程的替代品。面向对象的FP答案在于ML和Haskell的类型系统……特别是和类型、抽象数据类型、ML模块和Haskell类型类。

当然，仍然有一些设计模式是FP语言无法解决的。FP与单例的等价是什么?(暂时不考虑单例对象通常是一种糟糕的模式)

类型类做的第一件事是消除对单例对象的需求。

你可以浏览这23个名单，然后再剔除更多，但我现在没有时间。

我想引用Jeremy Gibbons的两篇优秀但有些密集的论文:《作为高阶数据类型泛型程序的设计模式》和《迭代器模式的精髓》(这两篇文章都可以在http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/上找到)。

它们都描述了惯用函数构造如何覆盖其他(面向对象)设置中特定设计模式所覆盖的领域。

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

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

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

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

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

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

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

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

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

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.

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

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