23.Interpreter模式

[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 var);
}

public class AddExpression extends SymbolExpression {

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

    @Override
    public int interpreter(HashMap 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 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 var) {
        return var.get(this.key);
    }

}

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

    public Calculator(String expStr) {
        // 定义一个堆栈,安排运算的先后顺序
        Stack stack = new Stack();
        // 表达式拆分为字符数组
        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 var) {
        return this.expression.interpreter(var);
    }
}


/**
 * {@link http://blog.csdn.net/shine0181/article/details/7469636}
 * 

解释器模式的优点

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

解释器模式的缺点

* *
  • 解释器模式会引起类膨胀
  • * * 每个语法都要产生一个非终结符表达式,语法规则比较复杂时,就可能产生大量的类文
    * 件,为维护带来了非常多的麻烦。 * *
  • 解释器模式采用递归调用方法
  • * * 每个非终结符表达式只关心与自己有关的表达式,每个表达式需要知道最终的结果,必
    * 须一层一层地剥茧,无论是面向过程的语言还是面向对象的语言,递归都是在必要条件
    * 下使用的,它导致调试非常复杂。想想看,如果要排查一个语法错误,我们是不是要一个
    * 一个断点的调试下去,直到最小的语法单元。 * *
  • 效率问题
  • * * 解释器模式由于使用了大量的循环和递归,效率是个不容忽视的问题,特别是用于解析
    * 复杂、冗长的语法时,效率是难以忍受的。 *

    解释器模式使用的场景

    * *
  • 重复发生的问题可以使用解释器模式
  • * * 例如,多个应用服务器,每天产生大量的日志,需要对日志文件进行分析处理,由于各
    * 个服务器的日志格式不同,但是数据要素是相同的,按照解释器的说法就是终结符表达
    * 式都是相同的,但是非终结符表达式就需要制定了。在这种情况下,可以通过程序来一劳
    * 永逸地解决该问题。 * * 一个简单语法需要解释的场景 * * 为什么是简单?看看非终结表达式,文法规则越多,复杂度越高,而且类间还要进行递
    * 归调用(看看我们例子中的堆栈),不是一般地复杂。想想看,多个类之间的调用你需要
    * 什么样的耐心和信心去排查问题。因此,解释器模式一般用来解析比较标准的字符集,例
    * 如SQL语法分析,不过该部分逐渐被专用工具所取代。 * * 在某些特用的商业环境下也会采用解释器模式,我们刚刚的例子就是一个商业环境,而
    * 且现在模型运算的例子非常多,目前很多商业机构已经能够提供出大量的数据进行分析。
    * *

    解释器模式的注意事项

    * * 尽量不要在重要的模块中使用解释器模式,否则维护会是一个很大的问题。在项目中可以
    * 使用shell、JRuby、Groovy等脚本语言来代替解释器模式,弥补Java编译型语言的不足 。
    * 我们在一个银行的分析型项目中就采用JRuby进行运算处理,避免使用解释器模式的四则运算,
    * 效率和性能各方面表现良好。 * */ public class Client { // 运行四则运算 public static void main(String[] args) throws IOException { // String expStr = getExpStr(); // 赋值 // HashMap var = getValue(expStr); String expStr = "a+b-c"; HashMap 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 getValue(String exprStr) throws IOException { HashMap map = new HashMap(); // 解析有几个参数要传递 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与模式》之解释器模式

    你可能感兴趣的:(23.Interpreter模式)