自从我去年开始学习f#和OCaml以来，我已经阅读了大量的文章，这些文章坚持认为设计模式(尤其是Java中的)是命令式语言中缺失特性的变通方法。我发现的一篇文章给出了相当有力的主张:
Most people I've met have read
the Design Patterns book by the Gang of
Four (GoF). Any self respecting programmer
will tell you that the book is
language agnostic and the patterns
apply to software engineering in
general, regardless of which language
you use. This is a noble claim.
Unfortunately it is far removed from
the truth.
Functional languages are extremely
expressive. In a functional language
one does not need design patterns
because the language is likely so high
level, you end up programming in
concepts that eliminate design
patterns all together.
函数式编程(FP)的主要特性包括函数作为一类值、curry化、不可变值等。在我看来，OO设计模式是否接近这些特性并不明显。
此外，在支持OOP的函数式语言(如f#和OCaml)中，使用这些语言的程序员显然会使用与其他OOP语言相同的设计模式。事实上，现在我每天都在使用f#和OCaml，我在这些语言中使用的模式与我在Java中使用的模式之间没有明显的区别。
函数式编程消除了对面向对象设计模式的需求这一说法是否属实?如果是这样的话，你能发布或链接到一个典型的OOP设计模式的例子及其功能对等物吗?
函数式编程消除了对面向对象设计模式的需求这一说法是否属实?
函数式编程与面向对象编程不同。面向对象的设计模式不适用于函数式编程。取而代之的是函数式编程设计模式。
对于函数式编程，您不需要阅读面向对象设计模式书籍;你会读到其他关于FP设计模式的书籍。
语言无关的
不完全。对于面向对象语言，只有语言不可知。这种设计模式根本不适用于过程式语言。它们在关系数据库设计上下文中几乎没有意义。它们不适用于设计电子表格。
一个典型的OOP设计模式和它的功能对等物?
上述情况不应该存在。这就像要求将一段过程代码重写为OO代码。嗯……如果我将原始的Fortran(或C)翻译成Java，我所做的只是翻译它。如果我完全将其重写为面向对象范式，它将不再看起来像原始的Fortran或C语言——它将无法识别。
从面向对象设计到功能设计没有简单的映射。他们看问题的方式完全不同。
函数式编程(像所有编程风格一样)具有设计模式。关系数据库有设计模式，OO有设计模式，过程式编程有设计模式。任何事物都有设计模式，甚至是建筑物的结构。
设计模式——作为一个概念——是一种永恒的构建方式，与技术或问题领域无关。但是，特定的设计模式适用于特定的问题领域和技术。
每个人只要仔细思考自己在做什么，就会发现设计模式。
当你试着从“设计模式”(一般)和“FP vs . OOP”的层面来看待这个问题时，你会发现答案最多是模糊的。
但是，在这两个轴上深入研究，并考虑特定的设计模式和特定的语言功能，事情就会变得更清楚。
因此，例如，当使用具有代数数据类型和模式匹配、闭包、第一类函数等的语言时，一些特定的模式(如访问者、策略、命令和观察者)肯定会改变或消失。不过，GoF书中的其他一些模式仍然“存在”。
总的来说，我会说，随着时间的推移，特定的模式正在被新的(或正在流行的)语言特性所淘汰。这是语言设计的自然过程;随着语言变得越来越高级，以前只能在书中使用示例来调用的抽象现在成为特定语言特性或库的应用程序。
(顺便说一句:这是我最近写的一篇博客，上面有更多关于FP和设计模式讨论的链接。)
坚持住。
听到我声称已经取代了设计模式并揭穿了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的程序员是动态的。
