自从我去年开始学习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设计模式的例子及其功能对等物吗?
坚持住。
听到我声称已经取代了设计模式并揭穿了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的程序员是动态的。
OOP和GoF模式处理状态。OOP对现实进行建模，使代码库尽可能接近现实的给定需求。GoF设计模式是为解决原子现实问题而确定的模式。它们以语义的方式处理状态问题。
因为在真正的函数式编程中不存在状态，所以应用GoF模式没有意义。功能设计模式与GoF设计模式是不同的。与现实相比，每个功能设计模式都是人为的，因为函数是数学的构造，而不是现实。
函数缺乏时间的概念，因为无论当前时间是多少，它们总是返回相同的值，除非时间是函数参数的一部分，这使得处理“未来的请求”非常困难。混合语言混合了这些概念，使得这些语言不是真正的函数式编程语言。
Functional languages are rising only because of one thing: the current natural restrictions of physics. Todays processors are limited in their speed of processing instructions due to physical laws. You see a stagnation in clock frequency but an expansion in processing cores. That's why parallelism of instructions becomes more and more important to increase speed of modern applications. As functional programming by definition has no state and therefore has no side effects it is safe to process functions safely in parallel.
GoF模式并没有过时。它们至少对真实世界的需求建模是必要的。但是如果你使用函数式编程语言，你必须将它们转换成它们的混合等价物。最后，如果使用持久性，就没有机会只编写函数式程序。对于程序的混合元素，仍然需要使用GoF模式。对于任何其他纯功能性的元素，没有必要使用GoF模式，因为没有状态。
因为GoF模式对于真正的函数式编程不是必需的，这并不意味着不应该应用SOLID原则。SOLID原则超越了任何语言范式。
