解释器模式

来源:互联网 发布:asp.net mvc4高级编程 编辑:程序博客网 时间:2024/05/22 07:44

《android设计模式》读书笔记,方便记忆,如有侵权,请尽快联系我删除,谢谢


一。定义
  解释器模式(Interpreter Pattern)是一种比较少见的行为型模式,其提供一种解释语言的语法或表达式的方式,该模式定义了一个表达式接口,通过该接口解释一个特定的上下文。
  其可以当成是,解释一种类型的表达式的方法。
二。使用场景
(1)如果某个简单的语言需要解释执行而且可以将该语言中的语句表达为一个抽象语法树时,可以考虑使用解释器模式
(2)在某些特定的领域出现不断重复的问题时,可以将该领域的问题转化为一种语法规则下额语句,然后构建解释器来解释该语句。
三。代码实现
  模型实现及说明
*******************************************************************************************
package com.yinazh.designpattern;

//对解释器的抽象,用来实现解释器
//例如: a+b+c+d 类似的表达式,abcd为终结符表达式,+为非终结符表达式
//声明了一个抽象的解释操作父类,定义一个抽象解释方法,具体的实现在各个具体的子类解释器中完成
public abstract class AbstractExpression{
    //抽象的解析方法
public abstract void interpret(Context cts);
}

//终结符表达式
public class TerminalExpression extends AbstractExpression{
    //该方法中实现与终结符有关的解释操作
public void interpret(Context cts){
....
}
}

//非终结符表达式
public class NonterminalExpression extends AbstractExpression{
     //该方法中实现与非终结符有关的解释操作
public void interpret(Context cts){
......
}
}

//上下文环境,包含解释器之外的全局信息
public class Context{
}

public class Client{
public static void main(String[] args){
 //根据文法对特定句子构建抽象语法树后解释
}
}
*******************************************************************************************
  上面解释器模型做出了简单的说明,下面具体实现。比较常见的的场景就是对算术表达式的解释。如“m+n+p”,如果用解释器模型进行解释,那么mnp就是终结符号,而+是非终结符号。
*******************************************************************************************
package com.yinazh.designpattern;

//本例子中,没有像上面模型使用一个Context对象作为interpret方法的签名,而是使用运算结果作为参数返回,没有必要使用额外的对象存储信息
public abstract class ArithmeticExpression{
    //抽象的解析方法,返回解析得到具体的值
public abstract int interpret();
}

//数字解析器
public class NumExpression extends ArithmeticExpression{
private int num;

public NumExpression(int num){
this.num = num;
}

public int interpret(){
return num;
}
}

//运算符解释器,其中定义了2个ArithmeticExpression类型的成员变量来存储运算符两边的数字解释器
public abstract class OperatorExpression extends ArithmeticExpression{
protected ArithmeticExpression exp1, exp2;

public OperatorExpression(ArithmeticExpression exp1, ArithmeticExpression exp2){
this.exp1 = exp1;
this.exp2 = exp2;
}
}

//加法运算解释器
public class AdditionExpression extends OperatorExpression{
public AdditionExpression(ArithmeticExpression exp1, ArithmeticExpression exp2){
super(exp1, exp2);
}

public int interpret(){
return exp1.interpret() + exp2.interpret();
}
}

//减法运算解释器
public class SubtractionExpression extends OperatorExpression{
public SubtractionExpression(ArithmeticExpression exp1, ArithmeticExpression exp2){
super(exp1, exp2);
}

public int interpret(){
return exp1.interpret() - exp2.interpret();
}
}

public class Calculator{
    //声明一个栈存储并操作所有相关的解释器
private Stack<ArithmeticExpression> mExpStack new Stack<ArithmeticExpression>();

    //这个过程其实就是构建语法树
public Calculator(String expression){
    //声明2个ArithmeticExpression类型的临时变量,存储运算符左右两边的数字解释器
ArithmeticExpression exp1, exp2;
String[] elements = expression.split(" ");
for(int i = 0; i < elements.length; i++){
switch(elements[i].charAt(0)){
case "+":
exp1 = mExpStack.pop();
exp2 = new NumExpression(Integer.valueOf(elements[++i]));
mExpStack.push(new AdditionExpression(exp1, exp2));
break;
case "-":
exp1 = mExpStack.pop();
exp2 = new NumExpression(Integer.valueOf(elements[++i]));
mExpStack.push(new SubtractionExpression(exp1, exp2));
break;
default:
mExpStack.push(new NumExpression(Integer.valueOf(elements[i])));
break;
}
}
}
public int calculate(){
return mExpStack.pop().interpret();
}
}

public class Client{
public static void main(String[] args){
Calculator c = new Calculator("124 + 234 + 23523 + 2351");
System.out.println(c.calculate());
}
}
*******************************************************************************************
  从上可知,具体的文法规则与解释器之间其实是对应关系,大多数情况下,一条语法对应一个解释器。解释器模式并不包含构建抽象的语法树,其逻辑结构应该由客户根据具体的情况去生成。
  将一条具体的文法通过一个解释器解释,把复杂的文法规则分离为简单的功能进行解释,最后将其组合城一颗抽象语法树解释执行。这说明了解释器模式的本质:将复杂问题简单化,模块化,分离实现,解释执行。
四。总结
优点:灵活的扩展性,当对文法规则进行扩展延伸时,只需要增加相应的非终结解释器,并在构建抽象语法树时,使用到新赠的解释器对象进行具体的解释即可。
缺点:对于每一条文法都可以对应至少一个解释器,其会生成大量的类,导致后期维护困难;同时复杂的文法,在构建抽象语法树时,会显的异常繁琐,甚至有可能会出现需要构建多棵语法树的情况,因此对于复杂的文法并不推荐使用解释器模式。

0 0