和OOAD一样，面向对象编程与函数式编程的等价性是什么？

Question

我最近涉足了函数式编程(FP)的世界，我想知道如何为即使是中等大小的应用程序“从功能上思考”？尤其是w.r.t.FPs的分析与设计。

有了OOP，我们就可以从对象、属性和关系的角度进行思考。我们使用类图和序列图来建模我们的分析/设计。然而，在FPs的设计中，同样的模型似乎是不合适的。函数式编程的等效建模范例是什么？看起来DFDs也许是个不错的选择，但我可能错了。

例如:我正在考虑设计一个模拟垄断的游戏，这是一款使用Haskell的棋盘游戏，只是为了学习语言。在执行OOAD时，您会发现像board这样的类包含了附加属性/方法的items。您有可以在类图中捕获的player和其他各种对象及其关联关系。以及它们在序列图中的相互作用。然而，这些建模范式似乎不能很好地传递给功能程序。那么，你如何在功能上建模呢？

注意:我正在寻找具体的参考资料/例子来解释如何分析和设计功能程序，因为我来自于一种高度面向对象的思维/建模方式。

Answer 1

西蒙·佩顿·琼斯说：

您所用的语言深刻地影响了用该语言编写的程序的设计。例如，在面向对象的世界中，许多人使用UML来勾画一个设计。在Haskell或ML中，一个可以写类型签名。函数程序的许多初始设计阶段包括编写类型定义。但是，与UML不同的是，所有这些设计都包含在最终产品中，并且是经过机器检查的。

来源：编程大师

因此，与其绘制所有花哨的UML图，不如在设计阶段编写与undefined耦合的类型定义。

Answer 2

这些天来，我所有的编程都是由单人项目组成的。如果我与其他程序员合作进行一个项目，我认为编写类型定义和使用undefined是一种很好的方法。

但我知道你真正想要的是一些关于你如何学会功能性思考的建议。下面是一些想法。

在用Haskell编程时，我有两种方式来思考我正在编写的程序。

• 如果程序是数学的，我认为程序是一组方程。
• 否则，我倾向于认为程序是一个或多个数据转换链。(因此，DFDs或许是有用的。)

所以在你的垄断例子中，我的第一个想法是弄清楚我将如何代表董事会的状态(例如，哪些房产拥有房屋，谁拥有它们)。然后，我可能会有一个函数，当有人购买一处房产时，我会改变董事会的功能，而其他功能则是玩家可能会做的事情。(还有用于表示state、State和StateT的monads。我可能会使用它们，如果我觉得它们会使代码更清晰，但我通常会保持基本的开始。)

作为初学者，我经常犯的错误之一就是创建了许多不必要的类和数据类型。

Answer 3

简短的回答:组成较小的程序。

首先研究问题，然后开发一组小的操作(通常以组合子的形式)，这些操作在问题的上下文中是有意义的，最后，围绕这些操作构建解决方案。我的印象是，在Hackage上找到的所有包都遵循这种方法。

通过这种方式，最终的解决方案(通常情况下)是简单、清晰和优雅的。由于您可以欣赏到您为解决方案选择的上述一组小操作，因此至关重要；通过实践，您将开发明智地选择它的敏感性。

我的书建议是皮尔斯的功能算法设计，由理查德伯德，谷歌图书(预览)。在这本书中，你将学习函数式编程的计算方法，我认为这是最有价值的。