功能程序中的结构元素

Question

在面向对象中，我们有需求、用例和UML，它们可以形成一个很好的概念框架。目标是定义对象、它们的责任、行为和它们之间的交流。

什么是功能编程世界中的对象/责任，行为和沟通，以定义我们的程序结构的高度预览？

Answer 1

不确定这是否能完全满足你的问题，但有希望接近。

需求/用例/功能规范/任何所谓的工具仍然是沟通FP程序设计的好工具。但是，FP程序的可视化设计模型并不那么有趣。它相当于为每个用例定义输入和输出，以及将输入映射到输出的函数。无聊吧？好吧，一些解释..。

职责不同

OO类通常是三个不同概念的所有者:数据的当前状态(隐式概念)、数据结构(属性或getter)以及数据上的行为(方法)。

FP --如:使用纯函数编程--通常只处理其中的两件事。结构和行为。当前状态作为持久化关注点被推到系统的边缘。因此，例如，负责产品的模块将知道它具有哪些属性(结构)以及您可以执行的操作(行为)。但是，在执行操作之前，您必须告诉操作产品的当前状态。然后，它将返回一个新的产品副本与更改应用。

您可以在UML中将其建模为一个类，其中只有用于行为的静态方法。和一个数据类，其中所有属性都为结构只读。数据类将用作行为方法的输入/输出的一部分。但是将这些模块连接到其他模块是UML类型设计崩溃的地方，因为.

组织与

不同

使用OO，经常有许多相互关联的类相互通信。他们中的每一个人都拥有系统运行所需的部分状态。但是对于FP，上面描述的产品这样的模块通常是独立的，因为它们没有状态。它们只有在更高级别的函数(如placeOrder之类的用例函数)中才会被“连接”，从而调用更专门的函数(如Order.validate和Product.canBeOrdered)来帮助将输入转换为返回值。

这就是UML等工具应用于FP的原因，因为它们本质上是对状态图进行建模，但功能程序更像是函数调用层次结构。对功能程序建模的一种可能更有用的方法是使用这个问题注释中提到的数据流图。您还可以使用嵌套流程图，其中每个决策步骤都有自己的单独流程图来描述其内部流程。

我要断言，对专门的功能建模是浪费时间。它们通常很小，而且纯函数很容易重构，因此可以频繁更新它们。如果你降到这个水平，你可能会在更新你的设计模型的过程中遇到很多麻烦。您想要为其建立一个设计模型的最底层可能是用例函数。

然而，我还没有观察到程序设计模型是FP中常见的实践(也不是说UML是通用的.我本人从未用过它)。我看到的大多数FP设计方法的范围仅仅是从代码中自上而下定义函数签名。然后，在填写实现时，为更专门化的函数创建fn签名。将它们组织成模块，然后开始它们的实现。只要继续下去这个递归过程，直到你碰到海龟。

边

系统的边缘是事物开始变得与UML更兼容的地方。因为程序实际上需要知道当前的状态才是有用的。这是连接各种技术的地方，比如数据库、外部API调用等等。这个系统级的设计是我做过的唯一一种图表。

否则，用它们的输入和输出来定义用例(如果您愿意的话，可以在视觉上)是您建立功能程序设计模型的级别。定义输入结构、输出结构和将输入映射到输出的函数。