模型驱动的软件开发与 Haskell答案

【问题标题】：Model-driven Software Development vs. Haskell模型驱动的软件开发与 Haskell
【发布时间】：2011-08-19 08:56:27
【问题描述】：

只需阅读关于模型驱动软件开发 (MDSD) 的（德语）维基文章。总结维基定义：

MDSD 是关于 DRY 原则（不要重复自己）
MDSD 是关于 DSL（领域特定语言）和生成器的设计
通过 MDSD 可以更简洁地描述问题（通过相应 DSL 的更高抽象级别）。

由于我知道并使用高阶函数式编程，我想知道，我的实际问题是： MDSD 只不过是将高阶函数式编程提供的强大功能（一部分）注入到本来就缺乏这些功能的编程语言/范式中的一种绝望尝试吗？

（或者我理解错了，MDSD 甚至可以用来支持高阶函数式编程吗？）

【问题讨论】：

是的 ;-) （对于您的第一个问题）
我自己也问过类似的问题：stackoverflow.com/questions/2807629/… 而这个已经关闭（仍然对此很生气）stackoverflow.com/questions/3134825/…

标签： haskell functional-programming model-driven-development

【解决方案1】：

我更喜欢反过来看。 OOP、MDSD、TDD、领域驱动设计和许多其他的范式都只是……范式。它们是看待人们开发的软件开发任务的方法，以解决他们认为在他们面前的任何东西中缺乏的东西。事实证明，函数式编程做同样的事情——它赋予程序员抽象的能力，这在没有一流函数的语言中并不优雅。所以我不会说 MDSD 是为非函数式语言提供功能特性的绝望尝试，就像我说的是人们从不同的角度来解决相同的问题。

this 最近的 SO 问题的一些答案有不同的说法。 ShreevatsaR 说，“几乎所有你可以用宏做的事情都可以用高阶函数做”。 Matthias Benkard 说：“通过更精细的......像单子和箭头这样的概念，在一定程度上缓解了宏的缺乏。”其他 cmets 也呼应了相同的主题。您提到 MDSD 的原则之一是生成器。宏是编译时生成器。所以我会将他们的陈述翻译为一个论点，即 MDSD 在函数式语言中本质上很容易。

【讨论】：

【解决方案2】：

制作DSL（领域特定语言）（FP）和创建一大堆领域对象（OOP）（内部包含业务逻辑）之间有很大的不同对象）。

FP 可能会遇到与过程语言相同的问题（和优势）：行为和数据分离。 OOP 语言不鼓励这样做。这种分离称为Anemic Domain Model。

这种“分离”会使更改数据变得非常困难（使用 DSL 可能更糟）请参阅我的帖子：Handling incremental Data Modeling Changes in Functional Programming

然而，另一方面，改变行为并让事物全面无状态是 OOP 领域驱动设计的痛点。然而，像 AOP ITD's 和 元编程 这样的问题就变得不那么重要了。

Scala 和 Ruby 是混合这两种技术的好例子。

【讨论】：

使用 DSL 时，一种更容易更改数据的方法是将数据知识限制在一小部分原始操作中，并根据这些原始操作实现其余操作。然后，您可以通过将真实数据隐藏在不透明类型后面来强制执行此操作（在 Haskell 的情况下不导出数据构造函数）。
@hammer 虽然我同意你的观点，但我在创建 DSL 时遇到的真正问题是创建 DSL（至少在 Haskell 中）我发现自己没有专注于域而是相当复杂的迂腐 Haskell Monads、Combinators、Arrows 等等。（再次只是我的看法）。
@Adam Gent：这是由于您对 Haskell 的了解有限，而不是内在的。刚接触 OOP 的人会抱怨由于复杂的类定义和继承而无法专注于他们的问题。
@Adam Gent：我同意在某些情况下可能很难展示您的 DSL 是如何成为 Monad 的，但是一旦您这样做了，您就会免费获得很多东西。此外，在大多数情况下，您可以使用现有的转换器构建您的 monad。正如@camcann 所说，一旦你熟悉了它，它对于熟悉 OOP 的人来说就像继承一样自然。
@Adam Gent 我的公司有一个非常用haskell编写的快速变化的网络服务器。仅仅因为它不是开源软件并不意味着它不存在。 corp.galois.com/blog/2011/4/22/… 包含了几乎所有关于它的公开信息。