恕我说一句，函数式编程最重要的特点是，你只用表达式来编程——表达式中的表达式，表达式中的表达式，所有的表达式都计算到最后，最终的表达式“计算时使机器变热”。

以我之见，面向对象编程的最重要的特征是，您正在使用具有内部状态的对象进行编程。在纯函数中不能有内部状态——面向对象的编程语言需要语句来实现。(函数式编程中没有语句。)

你是在拿苹果和橘子作比较。面向对象编程的模式不适用于函数编程，因为函数式编程是使用表达式进行编程，而面向对象编程是使用内部状态进行编程。

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

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

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

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

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

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

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

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

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

GoF设计模式是为Simula 67的后代面向对象语言(如Java和c++)编写的变通方法。

设计模式处理的大多数“弊病”是由以下原因引起的:

statically typed classes, which specify objects, but are not themselves objects; restriction to single dispatch (only the leftmost argument is used to select a method, the remaining arguments are considered as static types only: if they have dynamic types, it's up to the method to sort that out with ad-hoc approaches); distinction between regular function calls and object-oriented function calls, meaning that object-oriented functions cannot be passed as functional arguments where regular functions are expected and vice versa; and distinction between "base types" and "class types".

在通用Lisp对象系统中，这些设计模式中没有一个不会消失，即使解决方案的结构本质上与相应的设计模式相同。(此外，该对象系统比GoF书早了十多年。Common Lisp在该书第一次出版的同一年成为了ANSI标准。)

就函数式编程而言，模式是否适用于它取决于给定的函数式编程语言是否具有某种对象系统，以及它是否模仿受益于模式的对象系统。这种类型的面向对象不能很好地与函数式编程相结合，因为状态的突变是最重要的。

构造和非突变访问与函数式编程兼容，因此与抽象访问或构造有关的模式可以适用:像工厂、Facade、代理、Decorator和访问者这样的模式。

另一方面，像状态和策略这样的行为模式可能不能直接应用于功能性OOP，因为状态突变是它们的核心。这并不意味着它们不适用;也许它们以某种方式与任何可用于模拟可变状态的技巧结合应用。

Peter Norvig的《动态编程中的设计模式》(Design Patterns in Dynamic Programming)对这一主题进行了深入的讨论，不过他讲的是“动态”语言而不是“函数式”语言(两者有重叠)。

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

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

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