从开源框架理解设计模式系列#Interpreter解释器模式

目录

what什么是解释器模式

why为什么需要解释器模式

how如何实现解释器模式 

开源框架经典案例

 Spring中EL表达式

Elasticsearch的RoleMapperExpression表达式解析

ShardingSphere对SQL的语法解析

加餐：ShardingSphere中ASTNode版本演进

使用场景

优缺点对比

优点

缺点

参考资料

---

what什么是解释器模式

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

        HeadFirst定义：当你需要实现一个简单的语言时，就使用解释器模式定义语法的类，并用一个解释器解释句子。每个语法规则都用一个类代表。

        几乎所有涉及到SQL相关的，涉及到DSL相关的，都少不了Expression模式，只是规则的差异，语法的涵义不同，比如Elasticsearch对DSL的解析，ShardingSphere和mybatis – MyBatis 3 对SQL的解析。

why为什么需要解释器模式

        说实话，这应该我用的最少的一个设计模式了，只有在自己制定语法规则的时候才用的上，印象中工作中只有两次，一次是蚂蚁的报表报送模式，里面涉及到复杂的取数分拣规则，因此自定义了一套语法，使用标准的解释器模式是解释。另外就是自定义了一个兼容Explorer、Elasticsearch、Odps语法的DSL，这也用到了解释器模式。

        这里应用GOF设计模式的解释：

        如果一种特定类型的问题发生的频率足够高, 那么可能就值得将该问题的各个实例表述为 一个简单语言中的句子。这样就可以构建一个解释器, 该解释器通过解释这些句子来解决该问 题。 例如，搜索匹配一个模式的字符串是一个常见问题。正则表达式是描述字符串模式的一 种标准语言。与其为每一个的模式都构造一个特定的算法，不如使用一种通用的搜索算法来 解释执行一个正则表达式，该正则表达式定义了待匹配字符串的集合。 解释器模式描述了如何为简单的语言定义一个文法, 如何在该语言中表示一个句子, 以及如何解释这些句子。解释器设计模式描述了如何为正则表达式定义一个文法, 如何表示一个特定的正则表达式, 以及如何解释这个正则表达式。

        解释器模式使用类来表示每一条文法规则。在规则右边的符号是这些类的实例变量。上面的 文法用五个类表示: 一个抽象类RegularExpression和它四个子类LiteralExpression、AlternationExpression、SequenceExpression和RepetitionExpression后三个类定义的变量代表子表达式。

         每个用这个文法定义的正则表达式都被表示为一个由这些类的实例构成的抽象语法树。例如,  抽象语法树：

how如何实现解释器模式 

         解释器模式包含以下主要角色。

1. 抽象表达式（Abstract Expression）角色：定义解释器的接口，约定解释器的解释操作，主要包含解释方法 interpret()。
2. 终结符表达式（Terminal Expression）角色：是抽象表达式的子类，用来实现文法中与终结符相关的操作，文法中的每一个终结符都有一个具体终结表达式与之相对应。
3. 非终结符表达式（Nonterminal Expression）角色：也是抽象表达式的子类，用来实现文法中与非终结符相关的操作，文法中的每条规则都对应于一个非终结符表达式。
4. 环境（Context）角色：通常包含各个解释器需要的数据或是公共的功能，一般用来传递被所有解释器共享的数据，后面的解释器可以从这里获取这些值。
5. 客户端（Client）：主要任务是将需要分析的句子或表达式转换成使用解释器对象描述的抽象语法树，然后调用解释器的解释方法，当然也可以通过环境角色间接访问解释器的解释方法。