演化架构和紧急设计: 使用 DSL

核心提示： DSL 特征DSL 为捕获惯用模式提供了很好的可供选择的语法，正如 Martin Fowler 所定义的，演化架构和紧急设计: 使用 DSL(8)，DSL 有 5 个主要特征， 计算机编程语言要成为一个 DSL，我将探索多种构建 DSL 的技术，在后续几期中，这个语言必须是一个计算机编程语言，如

DSL 特征

DSL 为捕获惯用模式提供了很好的可供选择的语法。正如 Martin Fowler 所定义的，DSL 有 5 个主要特征。

计算机编程语言

要成为一个 DSL，这个语言必须是一个计算机编程语言。如果没有这一限制，容易引起 “滑坡”，您遇到的所有事物都有可能是一个 DSL。如果您定义 DSL 术语太广泛，所有的上下文会话都可能是 DSL。例如，我有些同事是板球迷，当我同他们在一起时，他们总是不停的谈论板球，尽管他们是用英语，我也不明白他们在说什么。我缺乏适当的上下文，以至于我不能明白他们所用的单词。然而，我们可以使用 DSL 术语谈论板球和其他运动。但是如果没有范围定义，很难将其缩小到可用约束范围内 —因此 Fowler 坚持将其限制在计算机编程语言范围之内。

语言天性

Fowler 关于 DSL 的第二条准则是，它应该有 “语言天性”，这意味您的 DSL 对于非程序员至少是隐约可读的。语言天性包含多种格式，在后续几期中，我将向您展示其中的一些，我将继续探索 DSL —— 作为一种捕获惯用模式的方法 —— 的引用。

领域焦点

要成为一个合适的 DSL，该语言必须只关注一个特定的问题领域，尝试创建 DSL 的风险之一是使其太宽泛。DSL 是一个抽象机制，创建太宽泛的抽象会降低它的优势。

有限的表现力

限制表现力也是 DSL 的一个特点。很少能找到一个 DSL 含有诸如循环和判定的控制结构。DSL 应该特别关注它正在尝试描述的领域，而且也只能关注该领域。因此，相当多的 DSL 是声明式的，而不是指令式的。

非图灵完整的（Turing complete）

前面两个标准暗示了这一特征，但是在这里，我将正式确认它。您的 DSL 应当不是图灵完整的。事实上，人们认为在 DSL 中一个反模式将意外地变成图灵完整的。例如，经典的 UNIX® sendmail配置文件就是意外图灵完整的。您可以在 sendmail配置文件中写一个操作系统，如果您愿意，而且又有很多时间的话。

意外地变成图灵完整的是惊人的简单。一些熟悉的基础设施工具可以意外地进行这种转变 —例如，XSLT。确定一种语言是否是 DSL，有时候取决于其上下文。使用 XSLT 来将一种版本的本文转换成另一个版本的文本时，您就是将它作为 DSL 使用的。如果您使用 XSTL 解决汉诺塔问题，您是将它作为一种图灵完整语言使用的（并且您可能会找到一种新的爱好）。

结束语

这一期为使用 DSL 作为一种获取惯用模式的提取机制奠定了基础。DSL 在这方面做得很不错，因为它们很容易与常规 API 区分开，更倾向于声明式的，并改善了项目中开发人员与非开发人员之间的信息交流和反馈。下一期，我将探索多种构建 DSL 的技术。在后续几期中，我将逐一介绍几种可用于寻求发现和设计代码的 DSL 技术。