Java设计模式之-解释器模式(Interpreter)

解释器模式在我看来,应用范围很小,我想了很久,想举一个不是加减乘除运算的例子出来,但是很难......在设计模式一书中,它的意图也被定义为实现一种语言所要运用的模式,我在网上找了一篇比较容易理解的文章,在此贴出来供大家阅读。http://www.jb51.net/article/79590.htm

这篇文章主要介绍了解析Java的设计模式编程之解释器模式的运用,文中对解释器模式的优缺点及适用场景作出了分析,需要的朋友可以参考下

定义:给定一种语言,定义他的文法的一种表示,并定义一个解释器,该解释器使用该表示来解释语言中句子。
类型:行为类模式
类图:

解释器模式

解释器模式是一个比较少用的模式,本人之前也没有用过这个模式。下面我们就来一起看一下解释器模式。

解释器模式的结构 抽象解释器:声明一个所有具体表达式都要实现的抽象接口(或者抽象类),接口中主要是一个interpret()方法,称为解释操作。具体解释任务由它的各个实现类来完成,具体的解释器分别由终结符解释器TerminalExpression和非终结符解释器NonterminalExpression完成。
终结符表达式:实现与文法中的元素相关联的解释操作,通常一个解释器模式中只有一个终结符表达式,但有多个实例,对应不同的终结符。终结符一半是文法中的运算单元,比如有一个简单的公式R=R1+R2,在里面R1和R2就是终结符,对应的解析R1和R2的解释器就是终结符表达式。

非终结符表达式:文法中的每条规则对应于一个非终结符表达式,非终结符表达式一般是文法中的运算符或者其他关键字,比如公式R=R1+R2中,+就是非终结符,解析+的解释器就是一个非终结符表达式。非终结符表达式根据逻辑的复杂程度而增加,原则上每个文法规则都对应一个非终结符表达式。
环境角色:这个角色的任务一般是用来存放文法中各个终结符所对应的具体值,比如R=R1+R2,我们给R1赋值100,给R2赋值200。这些信息需要存放到环境角色中,很多情况下我们使用Map来充当环境角色就足够了。

例子 来举一个加减乘除的例子吧,实现思路来自于《java与模式》中的例子。每个角色的功能按照上面提到的规范来实现。

//上下文(环境)角色,使用HashMap来存储变量对应的数值 
class Context 
{ 

    private Map valueMap = new HashMap(); 
    public void addValue(Variable x , int y) 
    { 
       Integer yi = new Integer(y); 
       valueMap.put(x , yi); 
    } 

    public int LookupValue(Variable x) 
    { 
       int i = ((Integer)valueMap.get(x)).intValue(); 
       return i ; 
    } 
} 

//抽象表达式角色,也可以用接口来实现 
abstract class Expression 
{ 
    public abstract int interpret(Context con); 
} 

//终结符表达式角色 
class Constant extends Expression 
{ 
    private int i ; 
    public Constant(int i) 
    { 
       this.i = i; 
    } 

    public int interpret(Context con) 
    { 
       return i ; 
    } 
} 

class Variable extends Expression 
{ 
    public int interpret(Context con) 
    { 
       //this为调用interpret方法的Variable对象 
       return con.LookupValue(this); 
    } 
} 

//非终结符表达式角色 
class Add extends Expression 
{ 
    private Expression left ,right ; 
    public Add(Expression left , Expression right) 
    { 
       this.left = left ; 
       this.right= right ; 
    } 

    public int interpret(Context con) 
    { 
       return left.interpret(con) + right.interpret(con); 
    } 
} 

class Subtract extends Expression 
{ 
    private Expression left , right ; 
    public Subtract(Expression left , Expression right) 
    { 
       this.left = left ; 
       this.right= right ; 
    } 

    public int interpret(Context con) 
    { 
       return left.interpret(con) - right.interpret(con); 
    } 
} 

class Multiply extends Expression 
{ 
    private Expression left , right ; 
    public Multiply(Expression left , Expression right) 
    { 
       this.left = left ; 
       this.right= right ; 
    } 

    public int interpret(Context con) 
    { 
       return left.interpret(con) * right.interpret(con); 
    } 
} 

class Division extends Expression 
{ 
    private Expression left , right ; 
    public Division(Expression left , Expression right) 
    { 
       this.left = left ; 
       this.right= right ; 
    } 

    public int interpret(Context con) 
    { 
       try{ 
              return left.interpret(con) / right.interpret(con); 
       }catch(ArithmeticException ae) 
       { 
           System.out.println("被除数为0!"); 
           return -11111; 
       } 
    } 
} 

//测试程序,计算 (a*b)/(a-b+2) 
public class Test 
{ 
    private static Expression ex ; 
    private static Context con ; 
    public static void main(String[] args) 
    { 
       con = new Context(); 
       //设置变量、常量 
       Variable a = new Variable(); 
       Variable b = new Variable(); 
       Constant c = new Constant(2); 

        //为变量赋值 
       con.addValue(a , 5); 
       con.addValue(b , 7); 

//运算,对句子的结构由我们自己来分析,构造 
       ex = new Division(new Multiply(a , b), new Add(new Subtract(a , b) , c)); 
       System.out.println("运算结果为:"+ex.interpret(con)); 
    } 
} 

解释器模式的优缺点 解释器是一个简单的语法分析工具,它最显著的优点就是扩展性,修改语法规则只需要修改相应的非终结符就可以了,若扩展语法,只需要增加非终结符类就可以了。
但是,解释器模式会引起类的膨胀,每个语法都需要产生一个非终结符表达式,语法规则比较复杂时,就可能产生大量的类文件,为维护带来非常多的麻烦。同时,由于采用递归调用方法,每个非终结符表达式只关心与自己相关的表达式,每个表达式需要知道最终的结果,必须通过递归方式,无论是面向对象的语言还是面向过程的语言,递归都是一个不推荐的方式。由于使用了大量的循环和递归,效率是一个不容忽视的问题。特别是用于解释一个解析复杂、冗长的语法时,效率是难以忍受的。

解释器模式的适用场景 在以下情况下可以使用解释器模式:
有一个简单的语法规则,比如一个sql语句,如果我们需要根据sql语句进行rm转换,就可以使用解释器模式来对语句进行解释。
一些重复发生的问题,比如加减乘除四则运算,但是公式每次都不同,有时是a+b-cd,有时是ab+c-d,等等等等个,公式千变万化,但是都是由加减乘除四个非终结符来连接的,这时我们就可以使用解释器模式。

注意事项 解释器模式真的是一个比较少用的模式,因为对它的维护实在是太麻烦了,想象一下,一坨一坨的非终结符解释器,假如不是事先对文法的规则了如指掌,或者是文法特别简单,则很难读懂它的逻辑。解释器模式在实际的系统开发中使用的很少,因为他会引起效率、性能以及维护等问题。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 159,117评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,328评论 1 293
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,839评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,007评论 0 206
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,384评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,629评论 1 219
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,880评论 2 313
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,593评论 0 198
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,313评论 1 243
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,575评论 2 246
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,066评论 1 260
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,392评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,052评论 3 236
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,082评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,844评论 0 195
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,662评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,575评论 2 270

推荐阅读更多精彩内容