设计模式——解释器模式

什么是解释器模式

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

Given a language, define a representation for its grammar along with an interpreter that uses the
representation to interpret sentences in the language.

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

UML

解释器角色：

AbstractExpression抽象解释器：具体的解释任务由各个实现类完成，具体的解释器分别由TerminalExpression和NonterminalExpression
TerminalExpression终结符表达式：实现与文法中的元素相关联的解释操作，通常一个解释器模式中只有一个终结表达式，但有多个实例，对应不同的终结符。
NonterminalExpression非终结符表达式：文法中的每条规则对应于一个非终结表达式，非终结符表达式根据逻辑的复杂程度而增加，原则上每个文法规则都对应一个非终结符表达式
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);
    }
}

解释器的优缺点

优点:

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

缺点:

解释器模式会引发类膨胀：每个语法都要产生一个非终结符表达式，语法规则比较复杂时，就可能产生大量的类文件，为维护带来了非常多的麻烦。
解释器模式采用递归调用方法：每个非终结符表达式只关心与自己有关的表达式，每个表达式需要知道最终的结果，必须一层一层的剥茧，无论是面向过程的语言还是面向对象的语言，递归都是在必要条件下是使用的，它导致调试非常复杂
效率问题：解释器模式由于使用了大量的循环和递归，效率是一个不容忽视的问题

解释器模式应用场景

重复发生的问题可以使用解释器模式
一个简单语法需要解释的场景

注意事项

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

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