设计模式：解释器模式

参考
23种设计模式（14）：解释器模式
设计模式（二十）解释器模式

解释器模式（据说用的非常少，我就没怎么研究了）

类型：行为型

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

角色

• 抽象解释器（AbstractExpression）：具体的解释任务由各个实现类完成。
• 终结符表达式（TerminalExpression）：实现与文法中的元素相关联的解释操作，通常一个解释器模式中只有一个终结表达式，但有多个实例，对应不同的终结符。
• 非终结符表达式（NonterminalExpression）：文法中的每条规则对应于一个非终结表达式，非终结符表达式根据逻辑的复杂程度而增加，原则上每个文法规则都对应一个非终结符表达式
• 上下文（Context）: 上下文环境类,包含解释器之外的全局信息
• 客户类（Client）: 客户端,解析表达式,构建抽象语法树,执行具体的解释操作等.

UML图

代码

class Context {}
abstract class Expression {
	public abstract Object interpreter(Context ctx);
}

class TerminalExpression extends Expression {
	public Object interpreter(Context ctx){
		return null;
	}
}

class NonterminalExpression extends Expression {
	public NonterminalExpression(Expression...expressions){
		
	}
	public Object interpreter(Context ctx){
		return null;
	}
}

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

文法递归的代码部分需要根据具体的情况来实现，因此在代码中没有体现。抽象表达式是生成语法集合的关键，每个非终结符表达式解释一个最小的语法单元，然后通过递归的方式将这些语法单元组合成完整的文法，这就是解释器模式。

优点

1. 扩展性强，若要新增乘，除，添加相应的非终结表达式，修改计算逻辑即可。

缺点

1. 需要建大量的类，因为每一种语法都要建一个非终结符的类。
2. 解释的时候采用递归调用方法，导致有时候函数的深度会很深，影响效率。