oop - 纯函数式编程上下文中的面向对象编程？

Question

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

我一直在用F#一段时间以来，我注意到我的函数越是无状态，我就越不需要将它们作为对象的方法。特别是，依靠类型推断使它们在尽可能多的情况下可用是有好处的。

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

在我看来，OOP 与具有作用于对象状态的方法密切相关，主要是为了改变对象。在不需要也不希望的纯 FP 上下文中。

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

我将感谢任何有关该问题的论文或反事实真实世界示例的引用。

Answer 1

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

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

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

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

现在，您可能想知道，OOP 的适当形式是什么？好吧，这是一个妙语:在很多方面，它比 ML 风格的 FP 更以功能为中心!我回引用one of my favorite papers关键区别似乎是:结构化数据(如 ML 风格语言中的代数数据类型)提供了数据的具体表示以及在其上定义操作的能力；对象提供了对行为的黑盒抽象和轻松替换组件的能力。

这里有一个比 FP 与 OOP 更深的二元性:它与一些编程语言理论家所说的 the Expression Problem 密切相关。 :对于具体数据，您可以轻松添加与之相关的新操作，但更改数据结构更加困难。使用对象，您可以轻松添加新数据(例如，新子类)，但添加新操作很困难(想想向具有许多后代的基类添加新抽象方法)。

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

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

编辑:我上面忘记提到的最后几件事。

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

在 Haskell 中不能很好地工作的是子类型。而且，虽然我认为继承和子类型在面向对象语言中经常被误用，但某种形式的子类型对于能够以灵活的方式组合对象非常有用。 Haskell 缺乏子类型的内在概念，并且手动替换使用起来非常笨拙。

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

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