1

我在想，方法名称和它们的调用似乎在你的代码中创建了一个 DSL，通过包装通用的东西并为你想要实现的目标适当地命名它。

你知道，所以很容易推断出下面的意思

if (a.isSubReportOf(b) || b.isSubReportOf(a)) {
    // do stuff
}

但是如果不研究它，方法中的代码可能真的很难解释。

我知道人们有时会认为整个 DSL 有什么特别之处——我们是否一直在代码中创建它们？

4

4 回答 4

2

我认为您指的是 Martin Fowler（也许还有其他人）所说的内部 DSL。读这个。

于 2009-02-10T21:51:09.313 回答
1

您可以交替询问是否应将 DSL 替换为经过深思熟虑的类、变量和方法名称。我总是把这与 Kent Beck 联系起来，因为他一直是“编写读起来像诗一样的代码”的支持者。

您正在发明领域词汇，将业务操作的语法制作成对象、方法和变量。对我来说听起来 DSL'ish ;)

于 2009-02-10T21:43:56.990 回答
1

这取决于您对 DSL 的定义，但对我来说，是的，我会这么说。DDD 是关于创建抽象的，它允许您拥有一种无处不在的语言并在更高级别上对概念进行推理。有些人可能会争辩说它本身不是 DSL，但更重要的问题是，像这样的代码是关于域的推理吗？

我会说是的，这才是真正重要的。

于 2009-02-10T21:45:09.703 回答
1

你能在足够复杂或简单的情况下一个接一个地替换吗？是的

他们是一样的吗？一点也不。

每个都有优点和缺点，这完全取决于需要什么。如果您需要在运行时对其进行修改，那么在编译语言中使用函数可能不是最好的解决方案（尽管它仍然是可能的），因为它对于您的需求来说太重了。

DSL 的目标是确定您的需求并制作一种仅包含这些需求的语言，以便尽可能简单地表示。这样，我们有限的大脑可以轻松地描绘出数据是什么，而无需编译程序。

此外，一个足够简单的 DSL 可以很容易地被另一个程序解析和编辑。毕竟，您制作了语法，并将其封装在库中，对吧？

在上面的示例中：

a.isSubReportOf(b) || b.isSubReportOf(a)

还是比说：

a <-> b
于 2009-02-10T21:51:09.563 回答