经过深思熟虑的方法/功能名称是否可以创建DSL？

Question

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

你知道，因此很容易推断下列内容的含义

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

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

我知道人们有时会认为整个DSL事情都有一些特别之处 - 我们是否一直在代码中创建它们？

Answer 1

我认为你指的是Martin Fowler（也许还有其他人）称之为内部DSL。阅读this。

Answer 2

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

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

Answer 3

这取决于你对DSL的定义，但对我来说，是的，我会这样说。 DDD就是创建抽象，让你拥有无处不在的语言和更高层次的概念理由。有些人可能认为它不是DSL本身，但更重要的问题是，代码就像关于域的推理？

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

Answer 4

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

它们是一样的吗？完全没有。

每个都有利弊，这一切都取决于需要什么。如果你需要它在运行时可以修改，那么在编译语言中使用函数可能不是最好的解决方案（虽然它仍然可以），因为它对你的需求来说太重了。

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

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

在上面的示例中：

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

在精神上仍然难以理解而不是说：

a <-> b