首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 软件管理 > 软件架构设计 >

解释器方式

2012-09-01 
解释器模式一、引子?  其实没有什么好的例子引入解释器模式,因为它描述了如何构成一个简单的语言解释器,主

解释器模式

一、引子?

  其实没有什么好的例子引入解释器模式,因为它描述了如何构成一个简单的语言解释器,主要应用在使用面向对象语言开发编译器中;在实际应用中,我们可能很少碰到去构造一个语言的文法的情况。

  虽然你几乎用不到这个模式,但是看一看还是能受到一定的启发的。

  二、定义与结构

  解释器模式的定义如下:定义语言的文法,并且建立一个解释器来解释该语言中的句子。它属于类的行为模式。这里的语言意思是使用规定格式和语法的代码。

  在GOF的书中指出:如果一种特定类型的问题发生的频率足够高,那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器,该解释器通过解释这些句子来解决该问题。而且当文法简单、效率不是关键问题的时候效果最好。

  这也就是解释器模式应用的环境了。

  让我们来看看神秘的解释器模式是由什么来组成的吧。

  1) 抽象表达式角色:声明一个抽象的解释操作,这个接口为所有具体表达式角色(抽象语法树中的节点)都要实现的。

  什么叫做抽象语法树呢?《java与模式》中给的解释为:抽象语法树的每一个节点都代表一个语句,而在每个节点上都可以执行解释方法。这个解释方法的执行就代表这个语句被解释。由于每一个语句都代表这个语句被解释。由于每一个语句都代表一个常见的问题的实例,因此每一个节点上的解释操作都代表对一个问题实例的解答。

  2) 终结符表达式角色:具体表达式。

  a) 实现与文法中的终结符相关联的解释操作

  b) 而且句子中的每个终结符需要该类的一个实例与之对应

  3) 非终结符表达式角色:具体表达式。

  a) 文法中的每条规则R::=R1R2…Rn都需要一个非终结符表带式角色

  b) 对于从R1到Rn的每个符号都维护一个抽象表达式角色的实例变量

  c) 实现解释操作,解释一般要递归地调用表示从R1到Rn的那些对象的解释操作

  4) 上下文(环境)角色:包含解释器之外的一些全局信息。

  5) 客户角色:

  a) 构建(或者被给定)表示该文法定义的语言中的一个特定的句子的抽象语法树

  b) 调用解释操作

  放上张解释器结构类图吧,这也是来自于GOF的书中。


解释器方式

?

?

?


  对于终结符,GOF建议采用享元模式来共享它们的拷贝,因为它们要多次重复出现。但是考虑到享元模式的使用局限性,我建议还是当你的系统中终结符重复的足够多的时候再考虑享元模式。

  四、优缺点

  解释器模式提供了一个简单的方式来执行语法,而且容易修改或者扩展语法。一般系统中很多类使用相似的语法,可以使用一个解释器来代替为每一个规则实现一个解释器。而且在解释器中不同的规则是由不同的类来实现的,这样使得添加一个新的语法规则变得简单。

  但是解释器模式对于复杂文法难以维护。可以想象一下,每一个规则要对应一个处理类,而且这些类还要递归调用抽象表达式角色,多如乱麻的类交织在一起是多么恐怖的一件事啊!

  五、总结

  这样对解释器模式应该有了些大体的认识了吧,由于这个模式使用的案例匮乏,所以本文大部分观点直接来自于GOF的原著。只是实例代码是亲自实现并调试通过的。

?

?

热点排行