22-解释器模式

解释器模式

一、定义

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

解释器模式的类图

AbstractExpression是抽象解释器；TerminalExpression是终结符表达式，实现与文法中的元素相关联的解释操作，通常一个解释器模式只有一个终结符表达式，但可以有多个实例，对应不同的终结符；NonterminalExpression是非终结符表达式，文法中的每个规则对应于一个非终结符表达式；Context是环境角色；

解释器通用源码

1. 抽象表达式

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

2. 终结符表达式

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

3. 非终结符表达式

   public class NonterminalExpression extends Expression {
       //每个非终结符表达式都会对其他表达式产生依赖
       public NonterminalExpression(Expression... expression){
       }
       public Object interpreter(Context ctx) {
           //进行文法处理
           return null;
       }
   }
   

4. 客户类

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

二、解释器模式的优点

• 扩展性高

  修改语法规则只有修改对应的非终结符表达式就可以了，若扩展语法则只要增加非终结符类就可以了。

三、解释器模式的缺点

• 解释器模式会引起类的膨胀

  每个语法都要产生一个非终结符表达式，语法规则复杂时，就会产生大量的类文件，维护变得麻烦

• 解释器模式采用递归调用方法

  每个非终结符表达式值关心与自己相关的表达式，每个表达式需要知道最终的结果必须一层层地递归执行下去。递归应该在必要条件下使用，它导致调试复杂，要排查递归里的错误，必须一层层的调试到最小语法单位。

• 效率问题

  解释器模式由于使用了大量的循环和递归，当解析复杂、冗长的语法时，效率会变得难以忍受。

四、解释器模式的使用场景

• 重复发生的问题可以使用解释器模式

  如日志解释时，多个服务器的日志格式不同，但是数据要素是相同的，也就是终结符表达式是相同的，只有为每个格式写出它的非终结符表达式，就可以同过程序不同的日志批量处理了

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

  非终结符表达式 语法规则越多，复杂度越高，而且类间还要进行递归调用，这样导致我们在这多个类之间排查问题变得给常困难，因此解释器模式一般解析比较标准的字符集，如sql语法等

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