[TOC]

解释器模式

解释器模式（Interpreter Pattern）是一种按照规定语法进行解析的方案，给定一个语言, 定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。

解释器能根据语法规则将输入的“语言”转化为指令执行，如sql的语法解析器，Python的解释器等等。

模式所涉及的角色如下所示：

（1）抽象表达式(Expression)角色：声明一个所有的具体表达式角色都需要实现的抽象接口。这个接口主要是一个interpret()方法，称做解释操作。

（2）终结符表达式(Terminal Expression)角色：实现了抽象表达式角色所要求的接口，主要是一个interpret()方法；文法中的每一个终结符都有一个具体终结表达式与之相对应。比如有一个简单的公式R=R1+R2，在里面R1和R2就是终结符，对应的解析R1和R2的解释器就是终结符表达式。

（3）非终结符表达式(Nonterminal Expression)角色：文法中的每一条规则都需要一个具体的非终结符表达式，非终结符表达式一般是文法中的运算符或者其他关键字，比如公式R=R1+R2中，“+"就是非终结符，解析“+”的解释器就是一个非终结符表达式。

（4）环境(Context)角色：这个角色的任务一般是用来存放文法中各个终结符所对应的具体值，比如R=R1+R2，我们给R1赋值100，给R2赋值200。这些信息需要存放到环境角色中，很多情况下我们使用Map来充当环境角色就足够了。

示例：加减运算解释器

代码

import java.util.HashMap;

public abstract class Expression {

    public abstract int interpreter(HashMap<String,Integer> var);
}

public class AddExpression extends SymbolExpression {

    public AddExpression(Expression _left, Expression _right) {
        super(_left, _right);
    }

    @Override
    public int interpreter(HashMap<String, Integer> var) {
        return left.interpreter(var) + right.interpreter(var);
    }

}

public class SubExpression extends SymbolExpression {

    public SubExpression(Expression _left, Expression _right) {
        super(_left, _right);
    }

    @Override
    public int interpreter(HashMap<String, Integer> var) {
        return left.interpreter(var) - right.interpreter(var);
    }

}

public abstract class SymbolExpression extends Expression {

    protected Expression left;

    protected Expression right;

    // 所有的解析公式都应只关心自己左右两个表达式的结果

    public SymbolExpression(Expression _left, Expression _right) {

        this.left = _left;

        this.right = _right;

    }

}

public class VarExpression extends Expression {
    private String key;

    public VarExpression(String key) {
        this.key = key;

    }

    @Override
    public int interpreter(HashMap<String, Integer> var) {
        return var.get(this.key);
    }

}

/**
 * Context
 * 
 */
public class Calculator {
    // 定义的表达式
    private Expression expression;
    // 构造函数传参,并解析

    public Calculator(String expStr) {
        // 定义一个堆栈，安排运算的先后顺序
        Stack<Expression> stack = new Stack<Expression>();
        // 表达式拆分为字符数组
        char[] charArray = expStr.toCharArray();
        // 运算
        Expression left = null;
        Expression right = null;
        for (int i = 0; i < charArray.length; i++) {
            switch (charArray[i]) {
            case '+': // 加法
                // 加法结果放到堆栈中
                left = stack.pop();
                right = new VarExpression(String.valueOf(charArray[++i]));
                stack.push(new AddExpression(left, right));
                break;
            case '-':
                left = stack.pop();
                right = new VarExpression(String.valueOf(charArray[++i]));
                stack.push(new SubExpression(left, right));
                break;
            default: // 公式中的变量
                stack.push(new VarExpression(String.valueOf(charArray[i])));
            }
        }
        // 把运算结果抛出来
        this.expression = stack.pop();

    }

    // 开始运算

    public int run(HashMap<String, Integer> var) {
        return this.expression.interpreter(var);
    }
}

/**
 * {@link http://blog.csdn.net/shine0181/article/details/7469636}
 * <h2>解释器模式的优点</h2>
 * 
 * 解释器是一个简单语法分析工具，它最显著的优点就是扩展性，修改语法规则只要修改</br>
 * 相应的非终结符表达式就可以了，若扩展语法，则只要增加非终结符类就可以了。</br>
 * <h2>解释器模式的缺点</h2>
 * 
 * <li>解释器模式会引起类膨胀</li>
 * 
 * 每个语法都要产生一个非终结符表达式，语法规则比较复杂时，就可能产生大量的类文</br>
 * 件，为维护带来了非常多的麻烦。
 * 
 * <li>解释器模式采用递归调用方法</li>
 * 
 * 每个非终结符表达式只关心与自己有关的表达式，每个表达式需要知道最终的结果，必</br>
 * 须一层一层地剥茧，无论是面向过程的语言还是面向对象的语言，递归都是在必要条件</br>
 * 下使用的，它导致调试非常复杂。想想看，如果要排查一个语法错误，我们是不是要一个</br>
 * 一个断点的调试下去，直到最小的语法单元。
 * 
 * <li>效率问题</li>
 * 
 * 解释器模式由于使用了大量的循环和递归，效率是个不容忽视的问题，特别是用于解析</br>
 * 复杂、冗长的语法时，效率是难以忍受的。
 * <h2>解释器模式使用的场景</h2>
 * 
 * <li>重复发生的问题可以使用解释器模式</li>
 * 
 * 例如，多个应用服务器，每天产生大量的日志，需要对日志文件进行分析处理，由于各</br>
 * 个服务器的日志格式不同，但是数据要素是相同的，按照解释器的说法就是终结符表达</br>
 * 式都是相同的，但是非终结符表达式就需要制定了。在这种情况下，可以通过程序来一劳</br>
 * 永逸地解决该问题。
 * 
 * 一个简单语法需要解释的场景
 * 
 * 为什么是简单？看看非终结表达式，文法规则越多，复杂度越高，而且类间还要进行递</br>
 * 归调用（看看我们例子中的堆栈），不是一般地复杂。想想看，多个类之间的调用你需要</br>
 * 什么样的耐心和信心去排查问题。因此，解释器模式一般用来解析比较标准的字符集，例</br>
 * 如SQL语法分析，不过该部分逐渐被专用工具所取代。
 * 
 * 在某些特用的商业环境下也会采用解释器模式，我们刚刚的例子就是一个商业环境，而</br>
 * 且现在模型运算的例子非常多，目前很多商业机构已经能够提供出大量的数据进行分析。</br>
 * 
 * <h2>解释器模式的注意事项</h2>
 * 
 * 尽量不要在重要的模块中使用解释器模式，否则维护会是一个很大的问题。在项目中可以</br>
 * 使用shell、JRuby、Groovy等脚本语言来代替解释器模式，弥补Java编译型语言的不足 。</br>
 * 我们在一个银行的分析型项目中就采用JRuby进行运算处理，避免使用解释器模式的四则运算，</br>
 * 效率和性能各方面表现良好。
 *
 */
public class Client {
    // 运行四则运算
    public static void main(String[] args) throws IOException {
        // String expStr = getExpStr();
        // 赋值
        // HashMap<String, Integer> var = getValue(expStr);
        String expStr = "a+b-c";
        HashMap<String, Integer> var = new HashMap<>();
        var.put("a", 100);
        var.put("b", 200);
        var.put("c", 1);
        Calculator cal = new Calculator(expStr);
        System.out.println("运算结果为：" + expStr + "=" + cal.run(var));
    }

    // 获得表达式
    public static String getExpStr() throws IOException {
        System.out.print("请输入表达式：");
        return (new BufferedReader(new InputStreamReader(System.in))).readLine();
    }

    // 获得值映射
    public static HashMap<String, Integer> getValue(String exprStr) throws IOException {
        HashMap<String, Integer> map = new HashMap<String, Integer>();
        // 解析有几个参数要传递
        for (char ch : exprStr.toCharArray()) {
            if (ch != '+' && ch != '-') {
                // 解决重复参数的问题
                if (!map.containsKey(String.valueOf(ch))) {
                    System.out.print("请输入" + ch + "的值:");
                    String in = (new BufferedReader(new InputStreamReader(System.in))).readLine();
                    map.put(String.valueOf(ch), Integer.valueOf(in));
                }
            }
        }
        return map;
    }
}

参考资料

[1] 解释器模式

[2] 《JAVA与模式》之解释器模式