您的位置:首页 > 其它

设计模式(21) 解释器模式(简单入门 行为模式)

2017-08-24 15:07 435 查看
设计图和源代码请访问我的github:https://github.com/yangsheng20080808/DesignModel

From Now On,Let us begin Design Patterns。

解释器模式(很少用呀,至少我就没用过,还是直接分享一下设计模式之禅给大家好了。)

定义

给定一门语言,定义它的方法的一种表示,并定义一个解释器,该解释器使用表示来解释语言中的句子。 Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.

都不用的模式没必要多哔哔。

通用类图:

解释器模式的优点:

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

解释器模式的缺点:

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

由于采用递归调用方法,每个非终结符表达式只关心与自己相关的表达式,每个表达式需要知道最终的结果,必须通过递归方式,无论是面向对象的语言还是面向过程的语言,递归都是一个不推荐的方式。

由于使用了大量的循环和递归,效率是一个不容忽视的问题。特别是用于解释一个解析复杂、冗长的语法时,效率是难以忍受的。

解释器模式的使用场景:

有一个简单的语法规则,比如一个sql语句,如果我们需要根据sql语句进行rm转换,就可以使用解释器模式来对语句进行解释。

一些重复发生的问题,比如加减乘除四则运算,但是公式每次都不同,有时是a+b-c*d,有时是a*b+c-d,等等等等个,公式千变万化,但是都是由加减乘除四个非终结符来连接的,这时我们就可以使用解释器模式。

解释器模式的注意事项:

尽量不要在重要的模块中使用解释器模式,否则维护是一个很大的问题。在项目中可以使用shell、JRuby、Groovy等脚本语言来代替解释器模式,弥补Java编译型语言的不足。(而且已有众多开源解释器,没必要自己写。),不建议使用。

解释器模式的例子:

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签:  设计模式