设计模式笔记--解释器模式

常用设计模式有23中，分为：

创建型模式（主要用于创建对象）

1、单例模式    2、工厂方法模式    3、抽象工厂模式    4、建造者模式     5、原型模式 
行为型模式 （主要用于描述对象或类是怎样交互和怎样分配职责）

1、模板方法模式  2、中介者模式  3、命令模式    4、责任链模式   5、策略模式   6、迭代器模式  

7、观察者模式      8、备忘录模式   9、访问者模式   10、状态模式   11、解释器模式

结构型模式(主要用于处理类或对象的组合)

1、代理模式  2、装饰模式   3、适配器模式   4、组合模式   5、外观模式（门面模式）   6、享元模式    7、桥梁模式

解释器模式

解释器模式（Interpreter Pattern）是一种按照规定语法进行解析的方案，在现在项目中使用较少，其定义如下：

给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。

● AbstractExpression——抽象解释器

具体的解释任务由各个实现类完成，具体的解释器分别由TerminalExpression和NonterminalExpression完成。

● TerminalExpression——终结符表达式

实现与文法中的元素相关联的解释操作，通常一个解释器模式中只有一个终结符表达式，但有多个实例，对应不同的终结符。具体到我们例子就是VarExpression类，表达式中的每个终结符都在栈中产生了一个VarExpression对象。

● NonterminalExpression——非终结符表达式

文法中的每条规则对应于一个非终结表达式，具体到我们的例子就是加减法规则分别对应到AddExpression和SubExpression两个类。非终结符表达式根据逻辑的复杂程度而增加，原则上每个文法规则都对应一个非终结符表达式。

● Context——环境角色

具体到我们的例子中是采用HashMap代替。  

解释器是一个比较少用的模式，  

其通用源码，可以作为参考   

抽象表达式通常只有一个方法，如代码清单27-8所示。

代码清单27-8 抽象表达式
public abstract class Expression {
//每个表达式必须有一个解析任务
public abstract Object interpreter(Context ctx);
}

抽象表达式是生成语法集合（也叫做语法树）的关键，每个语法集合完成指定语法解析 任务，它是通过递归调用的方式，最终由最小的语法单元进行解析完成。

终结符表达式如代码清单27-9所示。

代码清单27-9 终结符表达式
public class TerminalExpression extends Expression {
//通常终结符表达式只有一个，但是有多个对象
public Object interpreter(Context ctx) {
return null;
}
}

通常，终结符表达式比较简单，主要是处理场景元素和数据的转换。

非终结符表达式如代码清单27-10所示。

代码清单27-10 非终结符表达式
public class NonterminalExpression extends Expression {
//每个非终结符表达式都会对其他表达式产生依赖
public NonterminalExpression(Expression... expression){
}
public Object interpreter(Context ctx) {
//进行文法处理
return null;
}
}}

每个非终结符表达式都代表了一个文法规则，并且每个文法规则都只关心自己周边的文 法规则的结果（注意是结果），因此这就产生了每个非终结符表达式调用自己周边的非终结 符表达式，然后最终、最小的文法规则就是终结符表达式，终结符表达式的概念就是如此， 不能够再参与比自己更小的文法运算了。

客户类如代码清单27-11所示。

代码清单27-11 客户类
public class Client {
public static void main(String[] args) {
Context ctx = new Context();
//通常定一个语法容器，容纳一个具体的表达式，通常为ListArray、LinkedList、Stack等类型
Stack&Expression> stack = null;
for(;;){
//进行语法判断，并产生递归调用
}
//产生一个完整的语法树，由各个具体的语法分析进行解析
Expression exp = stack.pop();
//具体元素进入场景
exp.interpreter(ctx);
}
} 

通常Client是一个封装类，封装的结果就是传递进来一个规范语法文件，解析器分析后产生结果并返回，避免了调用者与语法解析器的耦合关系。  

优点 

解释器是一个简单语法分析工具，它最显著的优点就是扩展性，修改语法规则只要修改相应的非终结符表达式就可以了，若扩展语法，则只要增加非终结符类就可以了。 

缺点   

● 解释器模式会引起类膨胀  

● 解释器模式采用递归调用方法  

● 效率问题  

场景   

● 重复发生的问题可以使用解释器模式  

● 一个简单语法需要解释的场景  

注意事项   

尽量不要在重要的模块中使用解释器模式，否则维护会是一个很大的问题。

在项目中可以使用shell、JRuby、Groovy等脚本语言来代替解释器模式，弥补Java编译型语言的不足。我们在一个银行的分析型项目中就采用JRuby进行运算处理，避免使用解释器模式的四则运算，效率和性能各方面表现良好。  

准备使用解释器模式时，可以考虑一下Expression4J、MESP（Math Expression String Parser）、Jep等开源的解析工具包，功能都异常强大，而且非常容易使用，效率也还不错，实现大多数的数学运算完全没有问题，自己没有必要从头开始编写解释器。