解释器模式

Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.

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

解释器模式的通用类图

解释器模式的通用源码

抽象表达式

public abstract class AbstractExpression {

//每一个表达式必须有一个解析任务
public abstract Object interpreter(Context ctx);
}

终结符表达式

public class TerminalExpression extends AbstractExpression {

//通常终结符表达式只有一个，但是有多个对象
@Override
public Object interpreter(Context ctx) {
return null;
}

}

非终结符表达式

public class NonterminalExpression extends AbstractExpression {

//每个非终结符表达式都会对其他表达式产生依赖
public NonterminalExpression(AbstractExpression ...expressions ) {

}

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

}

环境角色

public class Context {

//定义表达式
private AbstractExpression expression;

//...
}

场景类

public class Client {

public static void main(String[] args) {

Context ctx = new Context();
//通常定一个语法容器，容纳一个具体的表达式、通常LinkedList、Stack等类型
Stack<AbstractExpression> stack = null;
for(;;) {
//进行语法判断，并产生递归调用
}
//产生一个完整的语法树，由各个具体的语法分析进行解析
AbstractExpression exp = stack.pop();
//具体元素进入场景
exp.interpreter(ctx);
}

}

解释器模式的优点

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

解释器模式的缺点

解释器模式会引起类膨胀。语法要是多且语法笔记哦啊复杂，就可能产生大量的类文件，维护带来了非常多的麻烦。

解释器模式采用递归调用方法。导致调试困难。

效率问题-较低。

解释器模式的使用场景

重复发生的问题可以使用解释器模式。如：多个应用服务器，每天产生大量的日志，需要对日志文件进行分析处理，由于各个服务器的日志格式不同，但是数据要素是相同的

一个简单的语法需要解释的场景。

解释器模式的注意事项

尽量不要在重要的模块中使用解释器模式，否则维护会一个很大的问题。在项目中可以使用shell、JRuby、Groovy等脚本语言代替解释器模式，弥补java编译语言的不足。