设计模式总结之Interpreter Pattern（解释器模式）

最新推荐文章于 2021-09-07 19:14:10 发布

迷死特兔

最新推荐文章于 2021-09-07 19:14:10 发布

阅读量1.6k

点赞数

分类专栏： Architecture 文章标签：设计模式 Interpreter Pattern 解释器模式

本文链接：https://blog.csdn.net/cooldragon/article/details/52175586

版权

Architecture 专栏收录该内容

29 篇文章 4 订阅

订阅专栏

Interpreter Pattern（解释器模式）

意图

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

结构

模式所涉及的角色如下所示：
　　（1）抽象表达式(Expression)角色：声明一个所有的具体表达式角色都需要实现的抽象接口。这个接口主要是一个interpret()方法，称做解释操作。
　　（2）终结符表达式(Terminal Expression)角色：实现了抽象表达式角色所要求的接口，主要是一个interpret()方法；文法中的每一个终结符都有一个具体终结表达式与之相对应。比如有一个简单的公式R=R1+R2，在里面R1和R2就是终结符，对应的解析R1和R2的解释器就是终结符表达式。
　　（3）非终结符表达式(Nonterminal Expression)角色：文法中的每一条规则都需要一个具体的非终结符表达式，非终结符表达式一般是文法中的运算符或者其他关键字，比如公式R=R1+R2中，“+"就是非终结符，解析“+”的解释器就是一个非终结符表达式。
　　（4）环境(Context)角色：这个角色的任务一般是用来存放文法中各个终结符所对应的具体值，比如R=R1+R2，我们给R1赋值100，给R2赋值200。这些信息需要存放到环境角色中，很多情况下我们使用Map来充当环境角色就足够了。

适用性

当有一个语言需要解释执行 , 并且你可将该语言中的句子表示为一个抽象语法树时,可使用解释器模式。而当存在以下情况时该模式效果最好:

* 该文法简单对于复杂的文法 , 文法的类层次变得庞大而无法管理。此时语法分析程序生 ?成器这样的工具是更好的选择。它们无需构建抽象语法树即可解释表达式 , 这样可以节省空间而且还可能节省时间。 ?

* 效率不是一个关键问题最高效的解释器通常不是通过直接解释语法分析树实现的 , 而是 ?首先将它们转换成另一种形式。例如,正则表达式通常被转换成状态机。但即使在这种情况下, 转换器仍可用解释器模式实现, 该模式仍是有用的。 ?

例子

SQL语句解析
XML/JSON解析
编程语言的编译器
正则表达式
…

优缺点

> 优点：
(1)易于改变和扩展文法。由于在解释器模式中使用类来表示语言的文法规则，因此可以通过继承等机制来改变或扩展文法。
(2)每一条文法规则都可以表示为一个类，因此可以方便地实现一个简单的语言。
(3)实现文法较为容易。在抽象语法树中每一个表达式节点类的实现方式都是相似的，这些类的代码编写都不会特别复杂，还可以通过一些工具自动生成节点类代码。
(4)增加新的解释表达式较为方便。如果用户需要增加新的解释表达式只需要对应增加一个新的终结符表达式或非终结符表达式类，原有表达式类代码无须修改，符合“开闭原则”。

> 缺点：
(1)对于复杂文法难以维护。在解释器模式中，每一条规则至少需要定义一个类，因此如果一个语言包含太多文法规则，类的个数将会急剧增加，导致系统难以管理和维护，此时可以考虑使用语法分析程序等方式来取代解释器模式。
(2)执行效率较低。由于在解释器模式中使用了大量的循环和递归调用，因此在解释较为复杂的句子时其速度很慢，而且代码的调试过程也比较麻烦。