Fork me on GitHub

大战设计模式【20】—— 解释器模式

解释器模式(Interpreter)

 

设计模式使用的例子https://github.com/LinkinStars/DesignPatternsAllExample

 

一、定义

定义一个语言的文法,并且建立一个解释器来解释该语言中的句子,这里的“语言”是指使用规定格式和语法的代码。

 

二、结构

AbstractExpression(抽象表达式):声明了抽象的解释操作;

TerminalExpression(终结符表达式):抽象表达式的子类,实现了与文法中的终结符相关联的解释操作,在句中的每一个终结符都是该类的一个实例;

NonterminalExpression(非终结符表达式):抽象表达式的子类,实现了文法中非终结符的解释操作,由于在非终结符表达式中可以包含终结符表达式,也可以继续包含非终结符表达式,因此其解释操作一般通过递归完成。

Context(环境类):又称为上下文类,用于存储解释器之外的一些全局信息,通常它临时存储了需要解释的语句。

 

三、优点

易于改变和扩展文法

增加新的解释表达式较为方便,只需对应新增一个新的终结符或非终结符表达式,原有代码无须修改,符合开闭原则

 

四、缺点

对于复杂文法难以维护

执行效率较低

 

五、应用场景

可以将一个需要解释执行的语言中的句子表示为一个抽象语法树

一些重复出现的问题可以用一种简单的语言来进行表达

一个语言的文法较为简单

执行效率不是关键问题,高效的解释器通常不是通过直接解释抽象语法树来实现的

 

六、个人总结

1、解释器模式通常使用的情况很少,本生我们不会经常去处理或者自己去构建一种语法结构的表达式去解释。

2、解释器模式主要就是用来解释你自定义的语法结构的数据

每个语法规则创建了一个类去专门处理

3、除非需要解释的东西语法规则较少,且解释行为简单,才考虑使用

 

 

 

参考博客:http://www.cnblogs.com/edisonchou/p/7512733.html
posted @ 2017-11-08 15:26  LinkinStar  阅读(240)  评论(0编辑  收藏  举报