功能规划的分析与设计

Edw*_*rzo 8 haskell functional-programming analysis software-design purely-functional

当您计划使用像Haskell这样的函数式编程语言开发系统时,如何处理分析和设计阶段?

我的背景是命令式/面向对象的编程语言,因此,我习惯使用案例分析和使用UML来记录程序的设计.但事实是,UML本质上与面向对象的软件方式有关.

我很感兴趣的是,为将要使用函数式编程开发的系统开发文档和定义软件设计的最佳方法是什么.

  • 您是否仍会使用用例分析或结构化分析和设计?
  • 软件架构师如何定义系统的高级设计,以便开发人员遵循它?
  • 当您应该展示解决方案的设计时,您向客户或新开发人员展示了什么?
  • 如何在不首先编写所有内容的情况下记录整个图片?
  • 在功能世界中有没有可与UML相媲美的东西?

Mar*_*cin -7

让我们来看看这个说法:

UML 本质上与面向对象的软件开发方式相关。

首先,这不是真的。无论实现是什么,您仍然可以在 UML 中对交互、用例、状态和数据模型进行建模。

其次,Haskell 的类型类是面向对象的一种形式:它们提供对其参数类型的多态分派(这允许使用该类型中存在的数据的不同函数实现)。

所以,是的,如果您确实想继续使用 UML,那就继续吧。

  • Haskell 的类型类不是面向对象的一种形式。它们是一种特殊的多态性,通常也可以从对象系统中获得。但它们不耦合数据和方法,这是面向对象的标志。 (12认同)
  • 它耦合了数据和方法的*类型*!http://www.haskell.org/haskellwiki/OOP_vs_type_classes (4认同)
  • @sclv是对的;Haskell 类型类比 OOP 类更接近 OOP 接口,但即使这样的类比也不完美。事实上,Haskell 中最接近 OOP 类的就是[包含函数和单子操作的数据类型](http://www.haskell.org/haskellwiki/FAQ#I.27m_making_an_RPG._Should_I_define_a_type_for_each_kind_of_monster.2C_and_a_type_class_for_them.3F)。 (2认同)
  • @sclv我不认为这是真的(尽管这是一个可以接受的“对孩子的谎言”)。如果你不考虑约束系统,类型类只是一个稍微受限制的对象系统。其中类型类具有 1. 子类型 2. 隐式自引用 3. 可替换自引用(又名继承)。类型类只是 oop 中的一个(参数化)抽象类,而实例只是从该抽象类继承的对象。有了 GHC 7.4 以及一些涉及 `newtype`、`unsafeCoerce` 和隐式参数的技巧,这种对应关系就变得完整了。 (2认同)