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

新的宣传是函数式编程,在许多书籍和教程中都有介绍。但是功能性软件工程呢? 在阅读关于Lisp和Clojure的文章时,我发现了两个有趣的陈述:

函数式程序通常是自底向上而不是自顶向下开发的(《论Lisp》,Paul Graham) 函数式程序员使用映射,而oop程序员使用对象/类(《Clojure for Java Programmers》,Rich Hickley谈话)。

那么,在Lisp或Clojure中,系统地(基于模型的)设计功能应用程序的方法是什么呢?常见的步骤是什么,我使用什么构件,我如何将它们从问题空间映射到解决方案空间?


当前回答

我最近发现了这本书: 功能和反应域建模

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

从书的描述:

Functional and Reactive Domain Modeling teaches you how to think of the domain model in terms of pure functions and how to compose them to build larger abstractions. You will start with the basics of functional programming and gradually progress to the advanced concepts and patterns that you need to know to implement complex domain models. The book demonstrates how advanced FP patterns like algebraic data types, typeclass based design, and isolation of side-effects can make your model compose for readability and verifiability.

其他回答

有一种“程序计算”/“通过计算设计”的风格与Richard Bird教授和牛津大学(英国)的代数编程组有关,我不认为将其视为一种方法论太牵强。

就我个人而言,虽然我喜欢AoP小组的工作,但我自己没有以这种方式实践设计的规程。但这是我的缺点,不是程序计算的缺点之一。

对于Clojure,我建议回到良好的旧式关系建模。《走出塔皮》是一本励志读物。

好吧,

一般来说,许多函数式编程语言在大学里被用来解决“小玩具问题”已经很长时间了。

由于“状态”的原因,OOP在“并行编程”方面有困难,因此它们现在变得越来越流行。有时函数式风格更适合解决手头的问题,比如谷歌MapReduce。

我敢肯定,当功能人员碰壁(尝试实现超过1.000.000行代码的系统)时,他们中的一些人会提出新的软件工程方法,并使用流行语:-)。他们应该回答这个老问题:如何将系统分成几部分,以便我们可以一次“咬”每一部分?使用功能风格[工作迭代,仪式和进化的方式]。

函数式风格肯定会影响我们的面向对象 风格。我们“保留”了功能系统中的许多概念并加以适应 我们的OOP语言。

但是函数式程序会被用于这样一个大系统吗?它们会成为主流吗?这就是问题所在。

没有人能提出现实的方法,而不实施这样一个大系统,弄脏自己的手。 首先你应该把自己的手弄脏,然后再提出解决方案。解决方案-没有“真正的痛苦和污垢”的建议将是“幻想”。

一种方法是在所选择的函数式编程语言中创建内部DSL。“模型”是用DSL表示的一组业务规则。

虽然这可能被认为是天真和简单的,但我认为“设计食谱”(一种应用于编程的系统解决问题的方法,如Felleisen等人在他们的书HtDP中所提倡的)将接近你所寻找的东西。

这里有一些链接:

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

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