走近“领域特定语言”（Domain-Specific Languages）

领域特定语言（Domain-Specific Languages，简称DSL），是一个很有用的术语和概念，但其边界很模糊。一些东西很明显是DSL，但另一些可能会引发争议。本文接下来就走近“领域特定语言”，了解它的概念、为何要采用DSL，以及使用时应该注意的问题。

1.定义DSL

• 领域特定语言（名词），针对某一特定领域，具有受限表达性的一种计算机程序设计语言。这一定义包含4个关键元素：
• 计算机程序设计语言（computerprogramming language）：人们用DSL指挥计算机去做一些事。同大多数现代程序设计语言一样，其结构设计成便于人们理解的样子，但它应该还是可以由计算机执行的语言。
• 语言性（languagenature）：DSL是一种程序设计语言，因此它必须具备连贯的表达能力——不管是一个表达式还是多个表达式组合在一起。
• 受限的表达性（limitedexpressiveness）：通用程序设计语言提供广泛的能力：支持各种数据、控制，以及抽象结构。这些能力很有用，但也会让语言难于学习和使用。DSL只支持特定领域所需要特性的最小集。使用DSL，无法构建一个完整的系统，相反，却可以解决系统某一方面的问题。
• 针对领域（domainfocus）：只有在一个明确的小领域下，这种能力有限的语言才会有用。这个领域才使得这种语言值得使用。

注意，“针对领域”在这个列表中最后出现，它纯粹是受限表达性的结果。很多人按字面意思把DSL理解为一种用于专用领域的语言。但字面意思常常有误：比如，我们不会管硬币叫“光盘”（Compact Disk，紧凑的盘），即便它确实是“盘”，而且相比于可以用这个术语称呼的东西，更为紧凑（compact）。

DSL主要分为三类：外部DSL、内部DSL，以及语言工作台。

• 外部DSL是一种“不同于应用系统主要使用语言”的语言。外部DSL通常采用自定义语法，不过选择其他语言的语法也很常见（XML就是一个常见选择）。宿主应用的代码会采用文本解析技术对使用外部DSL编写的脚本进行解析。一些小语言的传统UNIX就符合这种风格。可能经常会遇到的外部DSL的例子包括：正则表达式、SQL、Awk，以及像Struts和Hibernate这样的系统所使用的XML配置文件。
• 内部DSL是一种通用语言的特定用法。用内部DSL写成的脚本是一段合法的程序，但是它具有特定的风格，而且只用到了语言的一部分特性，用于处理整个系统一个小方面的问题。用这种DSL写出的程序有一种自定义语言的风格，与其所使用的宿主语言有所区别。这方面最经典的例子是Lisp。Lisp程序员写程序就是创建和使用DSL。Ruby社区也形成了显著的DSL文化：许多Ruby库都呈现出DSL的风格。特别是，Ruby最著名的框架Rails，经常被认为是一套DSL。
• 语言工作台是一个专用的IDE，用于定义和构建DSL。具体来说，语言工作台不仅用来确定DSL的语言结构，而且是人们编写DSL脚本的编辑环境。最终的脚本将编辑环境和语言本身紧密结合在一起。

多年来，这三种风格分别发展了自己的社区。你会发现，那些非常擅长使用内部DSL的人，完全不了解如何构造外部DSL。我担心这可能会导致人们不能采用最适合的工具来解决问题。我曾与一个团队讨论过，他们采用了非常巧妙的内部DSL处理技巧来支持自定义语法，但我相信，如果他们使用外部DSL的话，问题会变得简单许多。但由于对如何构造外部DSL一无所知，他们别无选择。因此，在本书中，把内部DSL和外部DSL讲清楚对我来说格外重要，这样你就可以了解这些信息，做出适当的选择。（语言工作台稍显粗略，因为它们很新，尚在演化之中。）

另一种看待DSL的方式是：把它看做一种处理抽象的方式。在软件开发中，我们经常会在不同的层面上建立抽象，并处理它们。建立抽象最常见的方式是实现一个程序库或框架。操纵框架最常见的方式是通过命令/查询式API调用。从这种角度来看，DSL就是这个程序库的前端，它提供了一种不同于命令/查询式API风格的操作方式。在这样的上下文中，程序库成了DSL的“语义模型”（第11章），因此，DSL经常伴随着程序库出现。事实上，我认为，对于构建良好的DSL 而言，语义模型是一个不可或缺的附属物。

谈及DSL，人们很容易觉得构造DSL很难。实际上，通常是难在构造模型上，DSL