演化架构与紧急设计: 语言、表达性与设计：第 1 部分

核心提示： 在 Groovy 示例中，您不需要显式地创建额外的类来实现定义该调用语义的接口，演化架构与紧急设计: 语言、表达性与设计：第 1 部分(7)，Groovy 中强大的 as 操作符接收一个代码块并生成一个新类来实现该接口，您可以像调用实现该接口的具体类一样调用它，并且它几乎没有语言级扩展点，在 G

在 Groovy 示例中，您不需要显式地创建额外的类来实现定义该调用语义的接口。Groovy 中强大的 as 操作符接收一个代码块并生成一个新类来实现该接口，您可以像调用实现该接口的具体类一样调用它。这样，在本例中，动态定义战略的所有代码块仍可作为正式具体类，实现 Calc 接口。

解释器模式

四人组解释器模式是一种特殊的情况。其定义为：

给定一种语言，定义其语法的表示法以及一个解释器，解释器会使用该表示法解释语言中的句子。

该模式本质上就是 “免交罚款出狱” 模式。它得到了 Philip Greenspun 的正式认可和支持，也就是 Greenspun's Tenth Rule（见 参考资料）：

任何足够复杂的 C 或 Fortran 程序都包含一个特别的非正式指定的、充斥着 bug 的缓慢实现，用于实现 Common Lisp 的部分功能。

他的意思是您用较弱的语言构建越来越复杂的软件时，您实际是在实现来自更为强大的语言（比如 Lisp）的特别功能，一次一个功能，却没能实现它。解释器模式承认您的基本语言或许不能胜任目前的任务，那么在这种情况下，最佳的解决方案是使用该语言在其之上构建一个更好的语言。

该模式展示了四人组书籍中想法的老化。四人组主张放弃核心语言并在其上构建全新的语言，创建您自己的 lexer、解析器、语法等等。但是该模式的中间阶段在过去的几年中已经发展成了主流（虽然从 Lisp 开始它就出现了）：通过在其上构建特定于域的语言（DSL）使您的语言更具表达性。

在 Java 语言之上构建 DSL 非常困难，因为该语言语法非常严格，并且它几乎没有语言级扩展点。在 Groovy 和 Ruby 之类的语言中构建 DSL 很常见，因为这些语法能够扩展并且包容性更好。