C#设计模式之16——解释器模式

C#设计模式之16——解释器模式

有些程序受益于以一种语言来描述其能够执行的操作。解释器模式描述的内容通常包括：定义该种语言的语法，并使用这一语法来解释以该种语言做陈述的语句。
当某个程序要处理多种不同但是又有些类似的情形时，使用一种简单的语言来描述这些情形让程序来解释这种语言回事一种非常好的有效的方式。这有些类似宏定义，通过宏定义，然后后面的解释器解释这个宏的操作。也有点类似在SQL查询语句中的例子，通过输入一个查询语句，后台解释器对SQL语言进行解释，然后返回给用户不同形式的数据。
在以下三种情况下需要使用解释器模式：
1. 当需要一个命令解释权来解析用户的命令的时候。
2. 当程序需要解析代数符号串的时候，比如需要计算一个数学表达式的值。
3. 当程序需要产生各种不同的输出的时候。就比如不同的SQL语句对应完全不用的用户数据输出。

我们首先需要定义用户使用语言的语法，然后根据这个语法来解析这个用户输入的语言。
解释语言一般分为三个步骤：
1. 把语言解释成标记符。
2. 把标记符规约成行为。
3. 实施行为。

在没有形式语言/ 编译器教育背景的编程者可能对这种模式不是很理解，因为里面用到了语言解析的一些规约方法。所以这里我们不把重点放在规约方法是，只要理解这种模式的基本实现方法就可以了。
我们需要做的有两个大步骤：
1. 构造能够分析语言的类，比如把语言分析出动词成分，名次成分等。然后分别用不同的类来获得实例。
2. 构造语法树，来解析用户输入的命令。这一般通过构造一个解析连，通过职责链模式完成这一部分的工作。通过递归的调用，直到有职责链中的某个节点可以解析一个成分为止。

完成语言的解析以后就需要对语言要完成的功能进行运算了。

解释器模式的优势是，一旦构建了通用的解析和规约工具以后，就可以非常容易的扩展或改进语法，还可以容易的添加语法中的词汇类型。
然而，解释器模式在解决一般的编程问题的时候并不是总是被用到，也不经常用到，迭代器模式反而是我们经常要用到的一种模式。
因为这里解释器模式的例子的代码非常多，就不单独给出代码了。之后会有所有模式的详细代码给出。