Haskell 演示 OOP 设计模式的等价物 [重复]

Posted 2023-03-15

【中文标题】Haskell 演示 OOP 设计模式的等价物 [重复]

【英文标题】：Haskell demonstration of equivalents to OOP Design Patterns [duplicate]

【发布时间】：2014-02-25 14:31:14

【问题描述】：

有人声称 OOP 设计模式与函数式语言无关。是否有代码演示如何在 Haskell 中实现每种模式？特别是，完整的演示还必须展示如何表示对象、OO 多态性等。

【问题讨论】：

您当然可以在 Haskell 中表示 OO 风格的对象、协变多态等，但它基本上相当于在 Haskell 的语法中创建一个 OO eDSL。这只是a bad idea to even start with thinking about OO design patterns，您应该从考虑特定的问题 以及它可能有哪些解决方案开始。在 OO 中，可能会出现一种设计模式，而在 Haskell 中则完全不同。

它们无关。为什么要代表不相关的东西？

【参考方案1】：

我认为“无关紧要”的部分说法更多是由于纯面向对象的概念与纯函数式编程不兼容。

在某些方面，它们都是旨在解决同一个问题的概念 - 代码管理、程序员的问题，以及以某种方式保持“状态”的组织。

OOP 通过尝试将每种状态隔离到一个单独的对象中来解决这个问题，然后让智能对象相互通信（通过方法、接口等）。

纯函数式语言通过将问题分解为非常小的函数并让数据相当笨拙来解决这个问题。一个函数不能访问、编辑或更改任何没有特别作为参数给出的东西，它对这些东西的作用只能在它返回的内容中看到。

以单例模式为例。

在 OOP 中，为了解决全局变量的问题，比如数据库连接，单例模式说你将所有数据库连接信息存储在一个对象中，然后只允许它被初始化一次，然后每当它初始化在整个代码库中初始化，相同的对象“出现”并使用相同的变量。

在haskell/函数式编程中，程序的整体结构会有所不同。相反，您将数据库连接功能隔离为仅在代码的一部分中发生。

您可以在 OOP 类型的语言中应用相同的东西，但这会更尴尬，而且语言设计也不鼓励这样做。

【参考方案2】：

FP 和 OOP 尝试用不同的方法解决相同的问题。 GoF 根本不适用，因为它们是 OOP 模式。您最好阅读“函数式编程的工艺”或“为您学习 Haskell for Great Good”之类的内容，以了解问题是如何通过函数式解决的。

我个人认为这两种方法都贡献了有用的东西，并且非常喜欢 Haskell 的类型类和完全多态的函数……DRY 的简单性和能力简直令人惊叹。也就是说，Scala 在将这两种方法合并为一种语言方面做得很好，因此您可以使用任何一种方法，具体取决于哪种方法似乎更适合该问题。