是否有用于功能编程的软件工程方法？[关闭]

今天所讲授的软件工程完全专注于面向对象的编程和“自然”的面向对象的世界观。有一种详细的方法学描述了如何将域模型转换为具有几个步骤和许多（UML）工件（如用例图或类图）的类模型。许多程序员已经内化了这种方法，并且对如何从头开始设计面向对象的应用程序有一个很好的主意。

新的炒作是函数式编程，许多书籍和教程都对此进行了讲授。但是功能软件工程呢？在阅读有关Lisp和Clojure的内容时，我得出了两个有趣的陈述：

1. 功能程序通常是自下而上而不是自上而下的开发（“ On Lisp”，Paul Graham）

2. 功能程序员使用Map，而OO程序员则使用对象/类（“ Rich Hickley的“ Java程序员的Clojure”）。

那么，对功能应用程序（即Lisp或Clojure）进行系统（基于模型？）设计的方法是什么？常见的步骤是什么，我使用什么工件，如何将它们从问题空间映射到解决方案空间？

感谢上帝，软件工程人员尚未发现功能编程。这里有一些相似之处：

• 许多OO“设计模式”被捕获为高阶函数。例如，“访问者”模式在功能界被称为“折叠”（或者，如果您是一个尖尖的理论家，则是“变形”）。在功能语言中，数据类型主要是树或元组，并且每种树类型都具有与之相关的自然分类。

  这些高阶函数通常带有某些编程定律，也称为“自由定理”。

• 功能性程序员使用图的方式比面向对象程序员少得多。OO图中表示的大部分内容都以类型或“签名”表示，您应该将其视为“模块类型”。Haskell还具有“类型类”，这有点像接口类型。

  那些使用类型的函数式程序员通常认为“一旦正确地使用了类型，代码便会编写自身。”

  并非所有功能语言都使用显式类型，但是How to Design Programs（如何设计程序）一书是学习Scheme / Lisp / Clojure的优秀书籍，很大程度上依赖于与类型紧密相关的“数据描述”。

那么，对功能应用程序（即Lisp或Clojure）进行系统（基于模型？）设计的方法是什么？

任何基于数据抽象的设计方法都可以正常工作。我碰巧认为，当语言具有显式类型时，这会更容易，但即使没有，它也可以工作。关于设计方法的抽象数据类型，这是很容易适应函数式编程，良好的开端是抽象和规范的程序开发芭芭拉Liskov的和约翰·加塔的第一版本。里斯科夫在这项工作中获得了图灵奖。

Lisp独有的另一种设计方法是，确定哪种语言扩展在您工作所在的问题领域中将很有用，然后使用卫生宏将这些构造添加到您的语言中。关于这种设计的一个好地方是Matthew Flatt的文章在Racket中创建语言。该文章可能在收费墙后面。您还可以通过搜索“特定于领域的嵌入式语言”一词找到有关这种设计的更多通用材料。除了Matthew Flatt所涵盖的特定建议和示例之外，我可能会从Graham的On Lisp开始或ANSI Common Lisp开始。

常见的步骤是什么，我要使用哪些工件？

常用步骤：

1. 识别程序中的数据及其上的操作，并定义代表该数据的抽象数据类型。

2. 确定常见的运算或计算模式，并将其表示为高阶函数或宏。期望将这一步骤作为重构的一部分。

3. 如果您使用的是类型化的功能语言，请尽早并经常使用类型检查器。如果您使用的是Lisp或Clojure，则最佳实践是首先编写包括单元测试在内的功能合同，这是最大程度地由测试驱动的开发。您将要使用已移植到平台的任何版本的QuickCheck，在您的情况下，它看起来像是ClojureCheck。它是一个功能强大的库，用于构建使用高阶函数的代码的随机测试。

对于Clojure，我建议回到良好的旧关系模型。在Tar​​pit外面是一本鼓舞人心的读物。

我个人发现，面向对象开发中的所有通常的良好做法也适用于函数式编程-只需进行一些小的调整即可考虑函数式世界观。从方法论的角度来看，您实际上不需要做任何根本不同的事情。

我的经验来自于近年来从Java迁移到Clojure。

一些例子：

• 了解您的业务领域/数据模型 -无论您要设计对象模型还是使用嵌套映射创建功能性数据结构，都同样重要。在某些方面，FP会更容易，因为它鼓励您将数据模型与功能/过程分开考虑，但您仍然必须同时考虑两者。

• 设计中的面向服务 -从FP角度来看，实际上效果很好，因为典型的服务实际上只是具有某些副作用的功能。我认为，Lisp世界中有时拥护的软件开发的“自下而上”观点实际上只是另一种形式的良好的面向服务的API设计原则。

• 测试驱动开发 -在FP语言中效果很好，实际上有时甚至更好，因为纯函数非常适合编写清晰，可重复的测试，而无需建立有状态的环境。您可能还希望构建单独的测试以检查数据完整性（例如，此映射是否具有我期望的所有键，以平衡在OO语言中类定义将在编译时为您强制执行的事实）。

• 原型制作/迭代 -与FP一样有效。如果您非常擅长构建工具/ DSL并在REPL上使用它们，则甚至可以与用户一起制作原型。

OO编程将数据与行为紧密耦合。函数式编程将两者分开。因此，您没有类图，但是您有数据结构，尤其是代数数据类型。可以将这些类型编写为与您的域非常匹配，包括通过构造消除不可能的值。

因此，没有书籍和书籍，但是有一种行之有效的方法，正如俗语所说，使不可能的价值无法代表。

这样，您可以选择将某些类型的数据表示为函数，或者相反，将某些功能表示为数据类型的并集，以便进行选择，例如，序列化，更严格的规范，优化等。 。

然后，鉴于此，您可以在adts上编写函数，以便建立某种 代数 -即，有固定的定律适用于这些函数。有些可能是幂等的-在多次应用后相同。有些是联想的。有些是可传递的，等等。

现在，您有了一个域，在该域​​上有可以根据行为规律进行组合的功能。一个简单的嵌入式DSL！

哦，有了给定的属性，您当然可以为它们编写自动随机测试（ala QuickCheck）..这仅仅是开始。

面向对象的设计与软件工程不是一回事。软件工程与我们从需求到工作系统的准时，低缺陷率的整个过程有关。函数式编程可能不同于OO，但是它并不能消除需求，高级和详细的设计，验证和测试，软件指标，估计以及所有其他“软件工程”。

此外，功能程序确实具有模块化和其他结构。您的详细设计必须根据该结构中的概念来表达。

一种方法是在选择的功能编程语言中创建内部DSL。然后，“模型”是在DSL中表达的一组业务规则。

请参阅我对另一篇文章的回答：

Clojure如何消除关注点分离？

我同意需要就如何使用FP方法构建大型应用程序这一主题编写更多的文章（此外，还需要做更多工作来记录FP驱动的UI）

尽管这可能被认为是幼稚和简单的，但我认为“设计秘诀”（Felleisen等人在其HtDP的书中提倡的一种系统化的解决问题的方法应用于编程）将与您所寻找的接近。

这里有几个链接：

http://www.northeastern.edu/magazine/0301/programming.html

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.86.8371

我最近找到了这本书： 功能和反应域建模

我认为这完全符合您的问题。

从书中描述：

功能和反应域建模教会您如何从纯函数的角度思考域模型，以及如何组合它们以构建更大的抽象。您将以函数式编程的基础知识开始，然后逐步发展为实现复杂域模型所需了解的高级概念和模式。该书演示了高级FP模式（如代数数据类型，基于类型类的设计以及副作用的隔离）如何使您的模型具有可读性和可验证性。

理查德·伯德教授和英国牛津大学的程序代数小组有一种“程序计算” /“按设计设计”的风格，我认为考虑到这种方法论并不为过。

就我个人而言，尽管我喜欢AoP小组制作的作品，但我自己却没有纪律以这种方式实践设计。但这是我的缺点，而不是程序计算之一。

我发现行为驱动开发非常适合在Clojure和SBCL中快速开发代码。将BDD与功能语言结合使用的真正好处是，与使用过程语言相比，我倾向于编写比平时更精细的粒度单元测试，因为我将问题分解成较小的功能块要好得多。

老实说，如果您想为功能程序设计配方，请看一下Haskell的Prelude之类的标准功能库。在FP中，模式通常是由高阶过程（在函数上运行的函数）本身捕获的。因此，如果看到一个模式，通常会简单地创建一个高阶函数来捕获该模式。

fmap是一个很好的例子。此函数将一个函数作为参数，并将其应用于第二个参数的所有“元素”。由于它是Functor类型类的一部分，因此Functor的任何实例（例如列表，图形等）都可以作为第二个参数传递给此函数。它捕获了将函数应用于第二个参数的每个元素的一般行为。

好，

通常，许多功能性编程语言在大学中长期用于“小玩具问题”。

由于OOP由于“状态”而难以进行“并行编程”，因此它们现在变得越来越流行。有时，函数样式更适合解决诸如Google MapReduce这样的问题。

我确信，当功能人员碰壁时[尝试实现大于1.000.000行代码的系统]，其中一些人会附带带有流行词:-)的新软件工程方法。他们应该回答一个古老的问题：如何将系统分成多个部分，以便我们一次可以“咬”每个部分？[使用功能性样式进行工作迭代，确定性的进化方式]。

可以肯定的是，功能样式将影响我们的面向对象样式。我们从功能系统中“仍然”提取了许多概念，并适应了我们的OOP语言。

但是功能程序会用于如此大的系统吗？它们会成为主流吗？那是问题。

如果没有实施如此庞大的系统，没人会想到现实的方法论，这会使他的手变得肮脏。首先，您应该弄脏双手，然后提出解决方案。解决方案-没有“真正的痛苦和污垢”的建议将是“幻想”。