有些模式更容易在支持FP的语言中实现。例如，策略可以很好地使用闭包来实现。然而，根据上下文，您可能更喜欢使用基于类的方法来实现策略，例如策略本身非常复杂和/或共享您想使用模板方法建模的结构。

根据我在多范式语言(Ruby)中开发的经验，FP实现在简单的情况下工作得很好，但是在上下文更复杂的情况下，基于GoF OOP的方法更适合。

FP方法并没有取代OOP方法，而是对其进行了补充。

坚持住。

听到我声称已经取代了设计模式并揭穿了SOLID and DRY，许多人会更加恼怒。我没有人。尽管如此，我还是正确地建模了协作(制造)架构，并在我的网站http://www.powersemantics.com/上在线发布了构建过程的规则以及背后的代码和科学。

My argument is that design patterns attempt to achieve what manufacturing calls "mass customization", a process form in which every step can be reshaped, recomposed and extended. You might think of such processes as uncompiled scripts. I'm not going to repeat my (online) argument here. In short, my mass customization architecture replaces design patterns by achieving that flexibility without any of the messy semantics. I was surprised my model worked so well, but the way programmers write code simply doesn't hold a candle to how manufacturing organizes collaborative work.

制造=每个步骤都与一个产品相互作用 OOP =每个步骤都与自身和其他模块交互，像无用的上班族一样将产品从一点传递到另一点

这种架构永远不需要重构。还有一些关于中心化和分布式的规则会影响复杂性。但为了回答你的问题，函数式编程是另一组处理语义，而不是用于大规模定制流程的体系结构，其中1)源路由作为(脚本)文档存在，使用者可以在触发之前重写，2)模块可以轻松动态地添加或删除。

我们可以说OOP是“硬编码过程”范式，而设计模式是避免这种范式的方法。但这就是大规模定制。设计模式将动态过程体现为混乱的硬代码。没有任何意义。f#允许将函数作为参数传递，这意味着函数式语言和面向对象语言都试图自己完成大规模定制。

代表脚本的硬代码会让读者感到困惑吗?如果你认为你的编译器的消费者为这些特性买单，那就完全不是，但对我来说，这些特性是语义上的浪费。它们是毫无意义的，因为大规模定制的重点是使过程本身是动态的，而不仅仅是对使用Visual Studio的程序员是动态的。

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

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

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

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

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

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

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

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

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

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