函数式编程会取代GoF设计模式吗？

自从我去年开始学习F＃和OCaml以来，我已经阅读了大量文章，这些文章坚持认为设计模式（尤其是Java语言）是命令式语言中缺少功能的变通方法。 我发现一篇文章提出了相当有力的主张 ：

我遇到的大多数人都阅读过《四人帮》（GoF） 的《设计模式》一书 。 任何自以为是的程序员都会告诉您，该书与语言无关，并且无论您使用哪种语言，该模式通常适用于软件工程。 这是一个崇高的主张。 不幸的是，它与事实相去甚远。

函数式语言极富表现力。 在一种功能性语言中，不需要设计模式是因为该语言可能太高级了，您最终会在概念上进行编程，从而一起消除了所有设计模式。

函数式编程（FP）的主要功能包括一流的功能，柯里化的，不变的值等。在我看来，OO设计模式无法近似所有这些功能。

此外，在支持OOP的功能语言（例如F＃和OCaml）中，对我来说显而易见的是，使用这些语言的程序员将使用与其他OOP语言相同的设计模式。 实际上，现在我每天都使用F＃和OCaml，并且在这些语言中使用的模式与在用Java编写时使用的模式之间没有显着差异。

函数式编程消除了对OOP设计模式的需求，这有什么道理可言吗？ 如果是这样，您是否可以发布或链接到典型的OOP设计模式及其等效功能的示例？

---

#1楼

我认为只有两个GoF设计模式可以将功能编程逻辑引入自然的OO语言。 我考虑战略与指挥。 可以通过功能编程来修改其他一些GoF设计模式，以简化设计并保持目的。

---

#2楼

这是讨论此主题的另一个链接： http : //blog.ezyang.com/2010/05/design-patterns-in-haskel/

Edward在他的博客文章中用Haskell描述了所有23种原始GoF模式。

---

#3楼

本质上是 ！

• 当模式绕过缺失的特征（高阶函数，流处理...）时， 最终性会促进合成 。
• 一次又一次地重写模式实现的需求本身可以被视为一种语言嗅觉 。

此外，此页面（AreDesignPatternsMissingLanguageFeatures）提供了“模式/功能”转换表以及一些不错的讨论（如果您愿意的话）。

---

#4楼

GoF书明确地将自己与OOP联系在一起-标题是“设计模式-可重用的面向对象软件的元素”（重点是我的）。

---

#5楼

模式是解决类似问题的方法，这些问题一遍又一遍，然后得到描述和记录。 因此，不，FP不会替换模式。 但是，FP可能会创建新的模式，并使某些当前的“最佳实践”模式“过时”。

---

#6楼

GoF 设计模式正在为作为Simula 67的后代（如Java和C ++）的OO语言编写变通方案。

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

• 静态类型的类，它们指定对象，但本身不是对象；
• 对单调度的限制（仅使用最左边的参数来选择方法，其余的参数仅被视为静态类型：如果它们具有动态类型，则取决于该方法使用临时方法进行分类）；
• 常规函数调用与面向对象函数调用之间的区别，这意味着面向对象函数不能作为期望常规函数的函数参数传递，反之亦然； 和
• “基本类型”和“类类型”之间的区别。

尽管解决方案的结构与相应的设计模式基本相同࿰