个人博客:打开链接
一、解释器模式的定义
Interpreter Pattern
Given a language,define a representation for its grammer along with an interpret uses the representation to interpretwntences in the language.(给定一门语言,定义它的文法的一种表示,并定义一个解释器,该解释器使用该表示来解释语言中的句子)
二、解释器模式的通用类图
AbstractExpression抽象解释器:
具体的解释任务由各个实现类完成,具体的解释器分别由TerminalExpression和NonterminalExpression完成。
TerminalExpression终结符表达式:
实现与文法中的元素相关联的解释操作,通常一个解释器模式中只有一个终结符表达式,但有多个实例,对应不同的终结符。具体到我们例子就是VarExpression类,表达式中的每个终结符都在堆栈中产生了一个VarExpression对象。
NonterminalExpression非终结符表达式:
文法中的每条规则对应于一个非终结表达式,具体到我们的例子就是加减法规则分别对应到AddExpression和SubExpression两个类。非终结符表达式根据逻辑的复杂程度而增加,原则上每个文法规则都对应一个非终结符表达式。
Context 环境角色:
具体到我们的例子中是采用HashMap代替。
三、通用代码
抽象表达式:
public abstract class Expression {
// 解析任务
public abstract Object interpreter(Context ctx);
}
终结符表达式:
public class TerminalExpression extends Expression {
// 通常终结符表达式只有一个,但是有多个对象
@Override
public Object interpreter(Context ctx) {
return null;
}
}
非终结符表达式:
public class NonterminalExpression extends Expression {
// 每个非终结符表达式都会对其他表达式产生依赖
public NonterminalExpression(Expression... expression) {
super();
}
@Override
public Object interpreter(Context ctx) {
// 进行文法处理
return null;
}
}
客户类:
public class Client {
public static void main(String[] args) {
Context context = new Context();
// 通常定义一个语法容器,容纳一个具体的表达式--ListArray,LinkedList,Stack等类型
Stack<Expression> stack = null;
for (;;) {
// 进行语法树判断,并产生递归调用
}
Expression exp = stack.pop();
// 具体元素进入场景
exp.interpreter(context);
}
}
四、解释器模式的优点
- 语法分析工具
- 扩展性好
五、解释器模式的缺点
- 引起类的膨胀
- 采用递归–调用复杂
- 效率问题【循环和递归引起的】
六、解释器模式的使用场景
- 重复发生的问题【服务器日志的处理】
- 一个简单语法需要解释的场景【简单:减少循环和递归(SQL语法分析)】
七、解释器模式使用的注意事项
- 尽量不要在重要的模块使用–维护是个大问题
- 可以代替解释器模式的技术:shell,JRuby,Groovy等脚本语言
八、最佳实践
- 实际开发中使用的非常少:考虑效率、性能、维护等问题
- 在大中型的框架中可以看到–数据分析、报表设计、科学计算工具
- 站在巨人的肩膀【开源解析工具包】
- Expression4J
- MESP
- JEP