functional-programming - 如何在功能上处理来自外部系统的状态？

Question

我最近接触了函数式编程，并且学会了几种以引用透明的方式处理某些副作用的方法:

the State monad对于可变状态，例如更新变量

the IO monad用于 I/O，例如从/向控制台读取/写入

FRP用于图形和输入设备事件等交互性

但是现在大多数“现实世界”应用程序都与外部系统(如 Web 服务、数据库等)交互，这些系统可以由多个用户同时修改，它们具有状态、长时间运行的操作等。所以情况并不那么简单与上述类别一样:向系统询问实体的状态或试图控制它的结果取决于其状态。此外，交互性也是一个要求:有一些用户可以任意点击的 GUI，也许我们还必须自动响应来自系统的变化。

通过最大化纯函数的好处来设计和实现这类应用程序的模式是什么？或者上述一些方法可以以我没有想到的方式应用于这个问题吗？该语言(比如 Java 或 Scala)并不强制要求 100% 的纯度，所以我对实践经验支持的实用解决方案感兴趣。

Answer 1

我还没有做很多这种实际上以实际方式完成的事情，所以其他人希望能够做得更多。然而，我已经用 Scala 编写了一个 Android 应用程序，它有你的几个要求； UI 是交互式的，“状态”全部存储在 SQLite 数据库中。数据库和 UI 都需要与 Android 框架交互，这些框架非常面向 Java，因此不太适合 Scala 或函数式编程。

我所做的是采用类似于 MVC 设计的东西，其中模型部分被实现为一组仅支持纯操作的 ADT。这还有一个额外的优势，即模型代码完全独立于 Android 框架，因此可以在模拟器之外以我喜欢的任何方式对其进行测试。

这给我留下了 Controller ( View 是一个非常薄的层，主要是配置，Android 的工作方式)，加上“从数据库加载模型”和“将模型保存到数据库”的附加操作。作为 Scala，我只是用不纯代码实现了这些部分，这些代码调用纯模型代码来进行实际的数据操作。在 Haskell 中，这些部分可能完全在 IO monad[1] 中。

总而言之，这让我能够以纯粹的功能性术语来思考我的问题域，而不必在与外部系统交互时“违背常规”。数据库层变成了数据库模式和我用于数据模型的 ADT 之间的映射问题；处理这些操作可能失败的事实是 Controller (启动数据库操作)的责任，并且不会影响模型。 Controller 操作在概念上变得非常简单，例如“按下此按钮时，将当前状态设置为在当前状态上调用函数的结果，然后更新显示表”。最后，这种不纯的“胶水”代码比实际的模型代码要多得多，但我仍然认为以这种方式编写程序是一种胜利，因为我的应用程序的核心是处理复杂的结构化数据，所以做到这一点是最棘手的。其余的主要是编写乏味而不是难以设计。

当您的程序中有大量计算(不一定是大量数据，只是您实际在其上进行计算)时，这很有效。如果该程序几乎完全将不同的外部系统粘合在一起，那么您不一定有那么多收获。

[1] 请记住，IO monad 不仅仅用于从控制台读取/写入。结果受程序外部状态影响的建模操作正是 IO monad 为 ;通常，如果 IO monad 不是一直与外部系统交互(或者最好即使是)，Haskellers 会尽量避免在几乎整个程序中使用 IO monad。您可以对数据进行纯计算以响应来自“外部”的事件，甚至可以进行纯计算 的 为响应外部事件而需要执行的 IO 操作(如果这很复杂)。