解释器模式--Interpreter Pattern

最近和同事聊到安卓中必须要用解释器对数据封装后才能被用到view中，想想设计模式中也有解释器模式，笔记记录。

背景

       如果在系统中某一特定类型的问题发生的频率很高，此时可以考虑将这些问题的实例表述为一个语言中的句子，因此可以构建一个解释器，该解释器通过解释这些句子来解决这些问题。
      解释器模式描述了如何构成一个简单的语言解释器，主要应用在使用面向对象语言开发的编译器中。

在解释器模式结构图中包含如下几个角色： 
● AbstractExpression（抽象表达式）：在抽象表达式中声明了抽象的解释操作，它是所有终结符表达式和非终结符表达式的公共父类。 
● TerminalExpression（终结符表达式）：终结符表达式是抽象表达式的子类，它实现了与文法中的终结符相关联的解释操作，在句子中的每一个终结符都是该类的一个实例。通常在一个解释器模式中只有少数几个终结符表达式类，它们的实例可以通过非终结符表达式组成较为复杂的句子。 
● NonterminalExpression（非终结符表达式）：非终结符表达式也是抽象表达式的子类，它实现了文法中非终结符的解释操作，由于在非终结符表达式中可以包含终结符表达式，也可以继续包含非终结符表达式，因此其解释操作一般通过递归的方式来完成。 
● Context（环境类）：环境类又称为上下文类，它用于存储解释器之外的一些全局信息，通常它临时存储了需要解释的语句。 
在解释器模式中，每一种终结符和非终结符都有一个具体类与之对应，正因为使用类来表示每一条文法规则，所以系统将具有较好的灵活性和可扩展性。对于所有的终结符和非终结符，我们首先需要抽象出一个公共父类，即抽象表达式类，其典型代码如下所示：

class TerminalExpression extends  AbstractExpression {       public  void interpret(Context ctx) {              //终结符表达式的解释操作       }}

class TerminalExpression extends  AbstractExpression {       public  void interpret(Context ctx) {              //终结符表达式的解释操作       }}

class NonterminalExpression extends  AbstractExpression {       private  AbstractExpression left;       private  AbstractExpression right;       public  NonterminalExpression(AbstractExpression left,AbstractExpression right) {              this.left=left;              this.right=right;       }       public void interpret(Context ctx) {              //递归调用每一个组成部分的interpret()方法              //在递归调用时指定组成部分的连接方式，即非终结符的功能       }     }

class Context {     private HashMap map = new HashMap();     public void assign(String key, String value) {         //往环境类中设值     }     public String  lookup(String key) {         //获取存储在环境类中的值     }}

维基百科例子（四则运算）
1.例子中解析语法使用到stack构建表达式

2.表达式依赖表达式最后以递归形式进行计算。

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

解释器模式的缺点 
  首先，解释器模式会引起类膨胀。每个语法都要产生一个非终结符表达式，语法规则比较复杂时，就可能产生大量的类文件，为维护带来了非常多的麻烦。 

      其次，解释器模式采用递归调用方法。每个非终结符表达式只关心与自己有关的表达式，每个表达式需要知道最终的结果，必须一层一层的剥茧，无论是面向过程的语言还是面向对象的语言，递归都是在必要条件下使用的，它导致调试非常复杂，想想看，如果我们要排查一个语法错误，我们是不是要一个一个断点的调试下去直到最小的语法单元。 
      最后，效率问题，解释器模式由于使用了大量的循环和递归，效率是个不容忽视的问题，特别是用于解析复杂、冗长的语法时，效率是难以忍受的。 

 
 解释器模式使用的场景 
      一些重复发生的问题可以使用解释器模式。例如，多个应用服务器，每天产生大量的日志，需要对日志文件进行分析处理，由于各个服务器的日志格式不同，但是数据元素都是相同的，按照解释器的说法就是终结符表达式都是相同的，但是非终结符表达式就需要制定了，在这种情况下，可以通过程序来一劳永逸的解决该问题。 
        一个简单语法需要解释的场景。为什么是简单？看看非终结表达式，文法规则越多，复杂度越高，而且类间还要进行递归调用（看看我们例子中的堆栈），不是一般的复杂，想想看多个类之间的调用你需要什么样的耐心和信心去排查问题。因此，解释器模式一般用来解析比较标准的字符，例如 SQL语法分析，不过该部分逐渐被专用工具所取代。 
       在某些特用的商业环境下也会采用解释器模式，我们刚刚的例子就是一个商业环境，而且现在模型运算的例子非常多，原因就是目前很多商业机构已经能够提供出大量的数据进行分析了。 
 
 解释器模式的注意事项 
尽量不要在项目中使用解释器模式（那你还讲这么多！肃静肃静，学无止境，毕竟它也是一种设计模式），除非必要，那用什么来代替呢？可以使用 shell、JRuby、Groovy等脚本语言来代替，完全可以满足一些商业的分析过程，我们在一个银行的分析型项目中就采用 JRuby 进行运算处理，代替了使用解释器模式的四则运算。