1.5使用代码生成

在迄今为止的讨论中，要处理DSL，组装“语义模型”（第11章），然后执行语义模型，提供我们希望从控制器得到的行为。在语言圈子里，这种方式称为解释（interpretation）。在解释文本时，会先解析文本，然后程序立刻产生结果。（在软件圈子里，解释是个棘手的词语，它承载了太多含义，然而，这里严格限制为立即执行的形式。）
在语言领域里，与解释相对的是编译。在编译（compilation）时，先解析程序文本，产生中间输出，然后单独处理输出，提供预期行为。在DSL的上下文里，编译方式通常指的是代码生成（code generation）。
用状态机解释这个差异有点困难，因此，换用另外一个小例子。想象一下，有某种规则判定人们是否符合某种资格，也许是为了满足保险资格。比如，如图1-5所示，一个规则是年龄在21～40岁。这个规则可以是一个DSL，检查像我这样的候选人是否具备资格。
如果解释，资格判定处理器会解析规则，在执行时加载语义模型，也许是启动时加载。当检查某个候选人时，它会对 这个候选人运行语义模型，获得一个结果。
如图1-6所示，在编译的情况下，解析器会加载语义模型，把它当做资格-判定处理器构建过程的一部分。在构建期间，DSL处理器会产生一些代码，这些代码经过编译、打包，并且纳入资格判定处理器，也可能当做某种共享库。然后，运行这段中间代码，对候选人进行评估。

例子里的状态机使用的是解释：在运行时解析配置代码，并组成语义模型。但其实也可以生成一些代码，以免在烤面包机里出现解析器和模型代码。
代码生成通常很笨拙，因为它常常需要进行额外的编译步骤。为了构建程序，首先需要编译状态框架和解析器，其次运行解析器，为格兰特小姐的控制器生成源代码，然后编译生成的代码。这样做，构建过程就变得复杂许多。
然而，代码生成的一个优势在于，编写解析器和生成代码可以用不同的语言。在这个情况下，如果生成代码用的是动态语言，比如JavaScript或是JRuby，第二个编译步骤就可以省略。
如果所用DSL的语言平台缺乏支持DSL的工具，代码生成的作用也会凸显出来。比如，我们不得不在一些老式的烤面包机上运行这个安全系统，而它们又只能理解编译过的C，那我们可以这样做，实现一个代码生成器，使用组装的语义模型作为输入，产生可以编译为运行在老式烤面包机的C代码。在最近做的一些项目里，我们曾为MathCAD、SQL和 COBOL等生成代码。
许多与DSL相关的作品都会关注代码生成，更有甚者，把代码生成当做这个活动的主要目标。随之而来的就是，涌现了一大批文章和书籍，赞美代码生成的优点。然而，在我看来，代码生成仅仅是一种实现机制，实际上，大多数情况下 都用不到。当然，有很多情况必须要用代码生成，但的确有很多情况确实用不到。
许多人用了代码生成之后，就舍弃了语义模型，他们在解析输入文本之后，就直接产生生成的代码。虽然对于使用代码生成的DSL而言，这也是一种常见的方式，但除非是最简单的情况，否则不推荐任何人这么做。语义模型的存在，可以将解析、执行语义以及代码生成分开。整个活动会因为这个划分变得简单许多。它也给了我们改变自己想法的机会； 比如，无须修改代码生成的例程就可以把内部DSL改成外部DSL。类似地，可以很容易产生多种输出，而无须担心解析器变得复杂。就同一种语义模型而言，既可以用解释模型，也可以选择代码生成。
因此，在本书的大部分内容里，假设存在一个语义模型，它是DSL工作的核心。
常见的代码生成风格有两种。第一种是“第一遍”代码，这种代码是一个模板，之后要手动修改。第二种是确保生成代码绝对不需要手动修改，也许还要排除调试期间所加的追踪信息。我几乎总是倾向于后者，因为这样可以更自由地重 新生成代码。对DSL而言，这点尤其正确，因为我们希望对于DSL所定义的逻辑而言，它是主要的表现形式。这意味着，无论何时，要修改行为，必须能够轻松修改DSL。因此，我们必须保证，任何生成的代码都没有经过手动编辑，虽然它可以调用手写的代码，或者由手写的代码调用。