纯函数式编程环境中的面向对象编程？

Question

在函数式编程 (FP) 环境中使用面向对象编程 (OOP) 有什么优势吗？

我已经使用 F# 一段时间了，我注意到我的函数是无状态的，我越不需要将它们作为对象的方法。特别是，依靠类型推断使它们可以在尽可能广泛的情况下使用是有优势的。

这并不排除对某种形式的命名空间的需要，这与 OOP 正交。也不鼓励使用数据结构。事实上，FP 语言的实际使用在很大程度上取决于数据结构。如果您查看F Sharp 编程/高级数据结构中实现的 F# 堆栈，你会发现它不是面向对象的。

在我看来，OOP 与作用于对象状态的方法密切相关，主要是为了改变对象。在纯粹的函数式编程环境中，这是不需要或不需要的。

一个实际的原因可能是能够与 OOP 代码交互，就像 F# 与 .NET 一起工作一样。 。然而除此之外，还有什么原因吗？在 Haskell 世界中，编程更纯粹的 FP 是什么体验？

我将不胜感激任何有关该问题的论文或反事实的现实世界例子的参考。

Answer 1

您看到的脱节并不是 FP 与 OOP 之间的脱节。它主要是关于不变性和数学形式主义与可变性和非正式方法。

首先，让我们忽略可变性问题：您可以使用具有可变性的 FP 和具有不变性的 OOP。甚至比你更实用的 Haskell 也可以让你随心所欲地使用可变数据，你只需要明确什么是可变的以及事情发生的顺序；抛开效率问题不谈，几乎任何可变对象都可以构造并返回一个新的“更新”实例，而不是更改其自身的内部状态。

这里更大的问题是数学形式主义，特别是在与 lambda 演算几乎没有关系的语言中大量使用代数数据类型。您已经用 Haskell 和 F# 标记了它，但意识到这只是函数式编程领域的一半；与 ML 风格的语言相比，Lisp 家族具有非常不同、更加随心所欲的特征。如今广泛使用的大多数面向对象系统本质上都是非常非正式的——面向对象确实存在形式主义，但它们并没有像 ML 风格语言中的 FP 形式主义那样明确地被调用。

如果消除了形式主义的不匹配，许多明显的冲突就会消失。想要在 Lisp 之上构建一个灵活的、动态的、临时的 OO 系统吗？继续吧，它会工作得很好。想要向 ML 风格的语言添加形式化的、不可变的 OO 系统？没问题，只是不要指望它能很好地与 .NET 或 Java 配合使用。

---

现在，您可能想知道，什么是适合 OOP 的形式主义？嗯，重点是：在很多方面，它比 ML 风格的 FP 更以功能为中心！我将参考我最喜欢的论文之一来了解似乎是关键区别：结构化数据（例如机器学习风格语言中的代数数据类型）提供了数据的具体表示以及定义数据操作的能力；对象提供了行为的黑盒抽象以及轻松替换组件的能力。

这里有一个比 FP 与 OOP 更深入的二元性：它与一些编程语言理论家所说的密切相关表达式问题：对于具体的数据，您可以轻松添加与其一起使用的新操作，但更改数据的结构则更加困难。使用对象，您可以轻松添加新数据（例如，新子类），但添加新操作很困难（想象一下向具有许多后代的基类添加新的抽象方法）。

我之所以说OOP更以函数为中心，是因为函数本身代表了一种行为抽象形式。事实上，你可以在 Haskell 之类的东西中模拟 OO 风格的结构，方法是使用包含一堆函数的记录作为对象，让记录类型成为某种“接口”或“抽象基类”，并让创建记录的函数替换类构造函数。因此，从这个意义上说，面向对象语言使用高阶函数的频率远远高于 Haskell 等语言。

有关此类设计实际上在 Haskell 中得到很好使用的示例，请阅读 的源代码Graphics-DrawingCombinators 包，特别是它使用包含函数的不透明记录类型并仅根据其行为组合事物的方式。

---

编辑：最后一些我忘记在上面提到的事情。

如果 OO 确实广泛使用了高阶函数，那么乍一看它似乎应该非常自然地适合函数式语言（例如 Haskell）。不幸的是，情况并非如此。确实，我所描述的对象（参见 LtU 链接中提到的论文）非常适合。事实上，结果是一种比大多数面向对象语言更纯粹的面向对象风格，因为“私有成员”由用于构造“对象”的闭包隐藏的值表示，并且除了一个特定实例本身之外，其他任何东西都无法访问。没有比这更私密的了！

Haskell 中不太有效的是子类型。而且，尽管我认为继承和子类型在 OO 语言中经常被误用，但某种形式的子类型对于能够以灵活的方式组合对象非常有用。 Haskell 缺乏固有的子类型概念，并且手动替换往往非常笨拙。

顺便说一句，大多数具有静态类型系统的面向对象语言也通过对可替换性过于宽松并且不为方法签名中的差异提供适当的支持来实现子类型的完整散列。事实上，我认为至少据我所知，唯一没有完全搞砸的成熟的面向对象语言是 Scala（F# 似乎对 .NET 做出了太多让步，但至少我不认为它会犯任何新错误）。不过，我对许多此类语言的经验有限，所以我在这里肯定是错的。

在 Haskell 特定的注释中，它的“类型类”通常对 OO 程序员来说很有吸引力，对此我想说：不要去那里。尝试以这种方式实现 OOP 只会以泪水告终。将类型类视为重载函数/运算符的替代品，而不是 OOP。

Answer 2

至于 Haskell，类在那里不太有用，因为一些 OO 功能可以通过其他方式更容易实现。

封装或“数据隐藏”通常是通过函数闭包或存在类型而不是私有成员来完成的。例如，这是一个具有封装状态的随机数生成器的数据类型。 RNG 包含生成值和种子值的方法。因为类型“种子”是封装的，所以您唯一能做的就是将其传递给方法。

data RNG a where RNG :: (seed -> (a, seed)) -> seed -> RNG a

参数多态性或“泛型编程”上下文中的动态方法分派是由类型类（不是 OO 类）提供的。类型类就像 OO 类的虚拟方法表。但是，没有数据隐藏。类型类不像类方法那样“属于”数据类型。

data Coordinate = C Int Int

instance Eq Coordinate where C a b == C d e = a == b && d == e

子类型多态性或“子类化”上下文中的动态方法分派几乎是 Haskell 中使用记录和函数的类模式的翻译。

-- An "abstract base class" with two "virtual methods"
data Object =
  Object
  { draw :: Image -> IO ()
  , translate :: Coord -> Object
  }

-- A "subclass constructor"
circle center radius = Object draw_circle translate_circle
  where
    -- the "subclass methods"
    translate_circle center radius offset = circle (center + offset) radius
    draw_circle center radius image = ...

Answer 3

我认为有几种方法可以理解 OOP 的含义。对我来说，这不是关于封装可变状态，而是更多关于组织和构建程序。 OOP 的这个方面可以与 FP 概念完美结合使用。

我相信在 F# 中混合这两个概念是一种非常有用的方法 - 您可以将不可变状态与处理该状态的操作相关联。您将获得标识符“点”补全的出色功能、轻松使用 C# 中的 F# 代码的能力等，但您仍然可以使代码完美运行。例如，您可以编写如下内容：

type GameWorld(characters) = 
  let calculateSomething character = 
    // ...
  member x.Tick() = 
    let newCharacters = characters |> Seq.map calculateSomething
    GameWorld(newCharacters)

一开始，人们通常不会在 F# 中声明类型 - 您可以从编写函数开始，然后改进代码以使用它们（当您更好地理解域并知道什么是函数时）构建代码的最佳方式）。上面的例子：

• 仍然是纯函数式的（状态是字符列表，并且没有变异）
• 它是面向对象的 - 唯一不寻常的是所有方法都返回“世界”的新实例