Java解释器模式（Interpreter）

一、概述
      定义语言的文法，并且建立一个解释器来解释该语言中的句子。如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子，这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题，而且当文法简单，效率不是关键问题的时候效果最好。
二、结构图

      抽象解释器：声明一个所有具体表达式都要实现的抽象接口（或者抽象类），接口中主要是一个interpret()方法，称为解释操作。具体解释任务由它的各个实现类来完成，具体的解释器分别由终结符解释器TerminalExpression和非终结符解释器NonterminalExpression完成。
      终结符表达式：实现与文法中的元素相关联的解释操作，通常一个解释器模式中只有一个终结符表达式，但有多个实例，对应不同的终结符。终结符一半是文法中的运算单元，比如有一个简单的公式R=R1+R2，在里面R1和R2就是终结符，对应的解析R1和R2的解释器就是终结符表达式。
      非终结符表达式：文法中的每条规则对应于一个非终结符表达式，非终结符表达式一般是文法中的运算符或者其他关键字，比如公式R=R1+R2中，+就是非终结符，解析+的解释器就是一个非终结符表达式。非终结符表达式根据逻辑的复杂程度而增加，原则上每个文法规则都对应一个非终结符表达式。
      环境角色：用来存储解释器的上下文环境，比如需要解释的文法等。很多情况下我们使用Map来充当环境角色就足够了。
三、示例程序

public class Context {

}

public abstract class AbstractExpression {
	public abstract Object interpreter(Context context);
}

public class TerminalExpression extends AbstractExpression {
	@Override
	public Object interpreter(Context context) {
		return null;
	}
}

public class NonterminalExpression extends AbstractExpression {
	public NonterminalExpression(AbstractExpression... expressions) {

	}

	@Override
	public Object interpreter(Context context) {
		return null;
	}
}

public class Client {
	public static void main(String[] args) {
		String expression = "";
		char[] charArray = expression.toCharArray();
		Context ctx = new Context();
		Stack<AbstractExpression> stack = new Stack<AbstractExpression>();
		for (int i = 0; i < charArray.length; i++) {
			// 进行语法判断，递归调用
		}
		AbstractExpression exp = stack.pop();
		exp.interpreter(ctx);
	}
}

四、优缺点
      优点：解释器模式提供了一个简单的方式来执行语法，而且容易修改或者扩展语法，修改语法规则只需要修改相应的非终结符就可以了。一般系统中很多类使用相似的语法，可以使用一个解释器来代替为每一个规则实现一个解释器，而且在解释器中不同的规则是由不同的类来实现的，这样使得添加一个新的语法规则变得简单。
      缺点：解释器模式会引起类的膨胀，每个语法都需要产生一个非终结符表达式，语法规则比较复杂时，就可能产生大量的类文件，为维护带来非常多的麻烦。同时，由于采用递归调用方法，每个非终结符表达式只关心与自己相关的表达式，每个表达式需要知道最终的结果，必须通过递归方式，无论是面向对象的语言还是面向过程的语言，递归都是一个不推荐的方式。由于使用了大量的循环和递归，效率是一个不容忽视的问题。特别是用于解释一个解析复杂、冗长的语法时，效率是难以忍受的。
       注意事项：解释器模式真的是一个比较少用的模式，因为对它的维护实在是太麻烦了，想象一下，一系列非终结符解释器，假如不是事先对文法的规则特别清楚，或者是文法特别简单，则很难读懂它的逻辑。解释器模式在实际的系统开发中使用的很少，因为它会引起效率、性能以及维护等问题。
五、应用场景
（1）系统有一个简单的语言可供解释；
（2）一些重复发生的问题可以用这种简单的语言表达；
（3）效率不是主要的考虑。