解释器模式

一、概述

一般问题：如果一种特定类型的问题发生的频率足够高，且有固定文法。

核心方案：定义一个语言的文法，并且建立一个解释器来解释该语言中的句子。

设计意图：解释器模式用到的地方比较少，因为我们很少会自己去构造一个语言的文法，最容易想到的是编译器，设计编程语言的人才会用到。在日常开发中，能用到解释器模式的必然符合一定条件：语法规则固定，语义句式多变。

 

• Expression：抽象表达式，声明一个抽象的解释操作父类，并定义一个抽象的 interpret() 解释方法，其具体的实现在各个具体的子类解释器中完成。
• TerminalExpression：终结符表达式，实现了抽象表达式角色所要求的接口，主要是一个interpret()方法；文法中的每一个终结符都有一个具体终结表达式与之相对应。比如有一个简单的公式R=R1+R2，在里面R1和R2就是终结符，对应的解析R1和R2的解释器就是终结符表达式。
• NonterminalExpression：非终结符表达式，文法中的每一条规则都需要一个具体的非终结符表达式，非终结符表达式一般是文法中的运算符或者其他关键字，比如公式R=R1+R2中，“+”就是非终结符，解析“+”的解释器就是一个非终结符表达式。
• Context：上下文环境类，这个角色的任务一般是用来存放文法中各个终结符所对应的具体值，比如R=R1+R2，我们给R1赋值100，给R2赋值200。这些信息需要存放到环境角色中，很多情况下我们使用Map来充当环境角色就足够了。
• Client：客户类，解析表达式，构建抽象语法树，执行具体的解释操作等。

---

二、应用实战

以四则运算的解释器为例，我们剖析一个简单的加减法表达式：

 

TEx为TerminalExpression；NEx为NonterminalExpression。

从图上可以看出，语法解析是从局部到整体层层递归，最终解释出整个表达式。

具体代码设计如下：

ArithExpression为抽象表达式，对应Expression

/**
 * 抽象的解析方法 
 */ 
public abstract class ArithExpression { 
      public abstract int interpreter(); 
}

NumExpression为数字表达式，对应终结符表达式

public class NumExpression extends ArithExpression{ 
　　　　private int num; 
　　　　public NumExpression(int num){ 
　　　　　　　this.num = num; 
　　　　} 
　　　　@Override 
　　　　public int interpreter() { 
　　　　　　　　return num; //直接返回值
　　　　} 
}

OperatorExpression为运算符表达式，对应非终结表达式

public abstract class OperatorExpression extends ArithExpression{ 
　　　　protected ArithExpression exp1, exp2; 
　　　　public OperatorExpression(ArithExpression exp1, ArithExpression exp2){ 
　　　　　　　　this.exp1 = exp1; 
　　　　　　　　this.exp2 = exp2; 
　　　　}
 }

下面是加法和减法云算法符表达式，对应具体非终结表达式

public class Add extends OperatorExpression{ 
　　　　public Add(ArithExpression exp1, ArithExpression exp2) {
　　　　 　　　　super(exp1, exp2); 
　　　　} 
　　　　@Override 
　　　　public int interpreter() { 
　　　　　　　　return exp1.interpreter() + exp2.interpreter(); //两个终结表达式之和
　　　　} 
}

public class Minus extends OperatorExpression{ 
　　　　public Minus(ArithExpression exp1, ArithExpression exp2) {
　　　　 　　　　super(exp1, exp2); 
　　　　} 
　　　　@Override 
　　　　public int interpreter() { 
　　　　　　　　return exp1.interpreter() - exp2.interpreter(); //两个终结表达式之差
　　　　} 
}

文法已经给出，下面是重点的解释器：

    public class Calculator {
        //声明一个Stack栈储存并操作所有相关的解释器
        private Stack<ArithExpression> mExpStack = new Stack<ArithExpression>();

        /**
         * expression为四则表达式，这里对其作递归解释
         */
        public Calculator(String expression) {
            ArithExpression exp1,exp2; //声明两个ArithExpression类型的临时变量，储存运算符左右两边的数字解释器
            String[] elements = expression.split(" "); //根据空格分割表达式字符串
            //遍历表达式元素数组
            for (int i = 0; i < elements.length; i++) {
                switch (elements[i].charAt(0)) {
                    case '+':
                        exp1 = mExpStack.pop(); //如果是加号，则将栈中的表达式弹出作为运算符号左边参数
                        exp2 = new NumExpression(Integer.parseInt(elements[++i]));  //同时将运算符号数组下标的下一个元素构造为一个数字表达式
                        mExpStack.push(new Add(exp1, exp2));  //通过上面的两个数字表达式构造加法表达式
                        break;
                    case '-':
                        exp1 = mExpStack.pop(); //如果是减号，则将栈中的表达式弹出作为运算符号左边参数
                        exp2 = new NumExpression(Integer.parseInt(elements[++i]));  //同时将运算符号数组下标的下一个元素构造为一个数字表达式
                        mExpStack.push(new Minus(exp1, exp2));  //通过上面的两个数字表达式构造减法表达式
                        break;
                    default:
                        //如果为数字，直接构造数字表达式并压入栈
                        mExpStack.push(new NumExpression(Integer.valueOf(elements[i])));
                        break;
                }
            }
        }

        /**
         * 计算结果
         */
        public int calculate() {
            return mExpStack.pop().interpreter();
        }
    }

测试解释器：

    public class Client { 
        public static void main(String[] args) { 
            Calculator c = new Calculator("5 + 6 - 8"); 
            System.out.println("计算结果："+c.calculate()); 
        } 
    }

结果：

计算结果：3

---

三、总结

总结：解释器是一种行为型设计模式，给定一个语言之后，解释器模式可以定义出其文法的一种表示，并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子。

优点：

可扩展性比较好，文法规则进行扩展延伸时，只需要增加相应的非终结符解释器。

缺点：

• 可利用场景比较少
• 对于复杂的文法比较难维护
• 解释器模式会引起表达式类膨胀
• 循环和递归效率低