设计模式原则27----解释器模式

个人博客：打开链接

一、解释器模式的定义

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