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

解释器模式的定义是一种按照规定语法进行解析的方案,在现在项目中使用的比较少,其定义如下:
Given a language, define a representation for its grammar along with an interpreter that uses the
representation to interpret sentences in the language.
给定一门语言,定义它的文法的一种表示,并定义一个解释器,该解释器使用该表达式来解释语言中的句子。

解释器模式(Interpreter、Context、Expression)-LMLPHP

解释器角色:
1.AbstractExpression抽象解释器:具体的解释任务由各个实现类完成,具体的解释器分别由TerminalExpression和
NonterminalExpression
2.TerminalExpression终结符表达式:实现与文法中的元素相关联的解释操作,通常一个解释器模式中只有一个终结
表达式,但有多个实例,对应不同的终结符。
3.NonterminalExpression非终结符表达式:文法中的每条规则对应于一个非终结表达式,非终结符表达式根据逻辑的
复杂程度而增加,原则上每个文法规则都对应一个非终结符表达式
4.Context环境角色

 
 //抽象表达式
/*抽象表达式是生产语法集合(也叫语法树)的关键,每个语法集合完成指定语法解析任务,它是通过递归调用的方式,最终
由最小的语法单元进行解析完成*/
public abstract class Expression{
//每个表达式必须有一个解析任务
public abstract Object interpreter(Context context);
} //终结符表达式 主要是处理场景元素和数据的转换 如:a+b+c中的"a""b""c"
public class TerminalExpression extends Expression{
//通常终结符表达式只有一个,但是有多个对象
public Object interpreter(Context context){
return null;
}
} //非终结符表达式
/*
每个非终结符表达式都代表一个文法规则,并且每个文法规则都只关心自己周边的文法规则结果(注意是结果),因此
这就产生了每个终结符表达式调用自己周边的非终结符表达式,然后最终,最小的文法规则就是终结符表达式,终
结符表达式的概念就是如此,不能在参与比自己更小的文法运算了
*/
public class NonterminalExpression extends Expression{
//每个非终结符表达式都会对其他表达式产生依赖
public NonterminalExpression(Expression... expression){
} public Object interpreter(Context context){
//进行文法处理
return null;
}
} //场景类
public class Client{
public static void main(String[] args){
Context context=new Context();
//通常一个语法容器,容纳一个具体的表达式,通常为ListArray,LinkedList,Stack等类型
Stack<Expression> stack=null;
for(;;){
//进行语法判断,并产生递归调用
}
//产生一个完整的语法树,由各个具体的语法分析进行解析
Expression expression=stack.pop();
//具体元素进入场景
expression.interpreter(context);
}
}

解析器模式的优点:
解释器是一个简单语法分析工具,它最显著的优点就是扩展性,修改语法规则只要修改相应的非终结符表达式就
可以了,若扩展语法,则只要增加非终结符类就可以了
缺点:
1.解释器模式会引发类膨胀:每个语法都要产生一个非终结符表达式,语法规则比较复杂时,就可能产生大量的
类文件,为维护带来了非常多的麻烦。
2.解释器模式采用递归调用方法:每个非终结符表达式只关心与自己有关的表达式,每个表达式需要知道最终的
结果,必须一层一层的剥茧,无论是面向过程的语言还是面向对象的语言,递归都是在必要条件下是使用的,它导致
调试非常复杂
3.效率问题:解释器模式由于使用了大量的循环和递归,效率是一个不容忽视的问题
解释器模式使用的场景
1.重复发生的问题可以使用解释器模式
2.一个简单语法需要解释的场景

注意事项
尽量不要再重要的模块中使用解释器模式,否则维护会一个很大的问题。在项目中可以使用shell,jRuby,Groovy
等脚本语言来代替解释器模式,弥补Java编译型语言的不足。

常用的解释器模式工具包:Expression4J,MESP(Math Expression String parser),Jep等开源的解析工具包

05-12 08:01