[设计模式]解释器模式

 

解释器模式(Interpreter Pattern)是一种用得比较少的行为型模式,其提供了一种解释语言的语法或表达式的方式,该模式定义了一个表达式接口,通过该接口解释一个特定的上下文。解释器模式在实际运用上相对来说要少很多,因为我们很少会自己去构造一个语言的方法。

 

定义

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

 

使用场景

解释器模式的使用场景其实相广泛,总的概括大致有两种:

1.如果某个简单的语言需要解释执行而且可以将该语言中的语句表示为一个抽象语法树时可以考虑使用解释器模式。

2.在某些特定的领域出现不断重复的问题时,可以将该领域的问题转化为一种语法规则下的语句,无用中来解释该语句。

 

UML类图

AbstractExpression:抽象表达式,声明一个抽象的解释操作父类,并定义一个抽象的解释方法,其具体的实现在各个具体的子类解释器中完成。

TerminalExpression:终结符表达式,实现文法中与终结符有关的解释操作。文法中每一个终结符都有一个具体的终结表达式与之对应。

NonterminalExpression:非终结符表达式,实现文法中与非终结符有关的解释操作。

Context:上下文环境类,包含解释器之外的全局信息。

Client :客户类,解析表达式,构建抽象语法树,执行具体的解释操作等。

 

示例

一个比较常见的场景是对算术表达式的解释,如“m + n + p",如果我们使用解释器模式对该表达式,那么代表数字的m、n、p我们就可以看成是终结符号,而 + 算术运算符号则可当作非终结符号

 

/**
 * 抽象的算术运算解释器  为所有解释器共性的提取
 * @author Administrator
 *
 */
public abstract class ArithmeticExpression {
	
	/**
	 * 抽象的解析方法
	 * 具体的解析逻辑由具体的子类实现
	 * @return
	 */
	public abstract int interpret();
}

 

 

/**
 * 数字解释器
 * @author Administrator
 *
 */
public class NumExpression extends ArithmeticExpression{
	private int num;
	
	public NumExpression(int num) {
		this.num = num;
	}
	
	@Override
	public int interpret() {
		return num;
	}

}

 

 

 

OperatorExpression依然是不个抽象类,其声明两个ArithmeticExpression类型的成员变量存储运算符号两边的数字解释器

 

 

 

/**
 * 运算符号抽象解释器 为所有运算符号解释器共性的提取
 * @author Administrator
 *
 */
public abstract class OperatorExpression extends ArithmeticExpression{
	//声明两个成员变量存储运算符号两边的数字解释器
	protected ArithmeticExpression exp1,exp2;
	
	public OperatorExpression(ArithmeticExpression exp1, ArithmeticExpression exp2) {
		this.exp1 = exp1;
		this.exp2 = exp2;
	}
}

 

/**
 * 加法运算抽象解释器
 * @author Administrator
 *
 */
public class AdditionExpression extends OperatorExpression{

	public AdditionExpression(ArithmeticExpression exp1, ArithmeticExpression exp2) {
		super(exp1, exp2);
	}

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

}

除此之外,我们创建一个Calculator类来处理一些相关的业务。

 

 

/**
 * 处理与解释器相关的一些业务
 * @author Administrator
 *
 */
public class Calculator {
	//声明一个Stack栈存储并操作所有相关的解释器
	private Stack<ArithmeticExpression> mExpStack = new Stack<ArithmeticExpression>();
	
	public Calculator(String expression) {
		//声明两个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 '-' :
				mExpStack.push(new NumExpression(Integer.valueOf(elements[i])));  //若是数字,直接构造数字解释器并压入栈
				break;
			}
		}
	}
	
	/**
	 * 计算结果
	 * @return
	 */
	public int calculate(){
		return mExpStack.pop().interpret();
	}
}

Calculator类的逻辑很好理解,首先约定每个元素之间必须使用空格隔开,将其拆分为字符串数组,然后循环遍历,首先遍历到的元素是数字,那么将其作为参数构造一个NumExpression对象压入栈,其次是运算符,如果是加号我们则将刚才压入栈的数字作为参数构造一个NumExpression对象抛出作为加号左路边的数字解释器,右边的数字解释器我们只需要将当前数组下标+1获取到数组元素中当前加号右边的数字,将其作为参数构造一个NumExpression对象即可,这个过程其实就是在构建语法树,只不过我们将其单独封装在了一个类里。

 

 

/**
 * 处理与解释器相关的一些业务
 * @author Administrator
 *
 */
public class Calculator {
	//声明一个Stack栈存储并操作所有相关的解释器
	private Stack<ArithmeticExpression> mExpStack = new Stack<ArithmeticExpression>();
	
	public Calculator(String expression) {
		//声明两个ArithmeticExpression类型的临时变量,存储运算符左右两边的数字解释器
		ArithmeticExpression exp1,exp2;
		
		//根据空格分割表达式字符串
		String[] elements = expression.split(" ");
		
		if(elements == null){
			return;
		}
		/**
		 * 循环遍历表达式元素数组
		 */
		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;
			default :
				mExpStack.push(new NumExpression(Integer.valueOf(elements[i])));  //若是数字,直接构造数字解释器并压入栈
				break;
			}
		}
	}
	
	/**
	 * 计算结果
	 * @return
	 */
	public int calculate(){
		return mExpStack.pop().interpret();
	}
}

如果现在又想引入减法运算,定义一个减法解释器即可:

 

 

public class SubtractionExpression extends OperatorExpression{

	public SubtractionExpression(ArithmeticExpression exp1, ArithmeticExpression exp2) {
		super(exp1, exp2);
	}

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

}

还需要修改下Calculator类构建语法树的逻辑

 

 

case '-':
				exp1 = mExpStack.pop();
				exp2 = new NumExpression(Integer.valueOf(elements[++i]));
				mExpStack.push(new SubtractionExpression(exp1, exp2));
				break;
public class Client {
	public static void main(String[] args) {
		Calculator c = new Calculator("113 + 20 + 9 + 1033 + 6 - 11");
		System.out.println(c.calculate());
	}
	
	//运行结果:
	//1170
}


可以看到解释器模式的一个优点:就是灵活性强,如果想实现更多的运算法则,只需创建对应的运算解释器即可,但是混合运算要比简单的加减复杂得多,还要考虑不同符号的运算优先级。

 

具体的文法规则与解释器之间其实是由对应关系的,大多数情况下两者之间是一一对应的关系,即一条文法对应一个解释器,我们也可以为一条文法创建多个不同的解释器,但是反过来就不行,因为一个解释器不能即解释加法运算又解释减法,否则就违背了解释器的定义。

将一条具体的文法通过一个解释器解释,把复杂的文法规则分离为简单的功能进行解释,最后将其组合成一棵抽象语法树解释执行。至此我们可以看到解释器的本原理和本质:将复杂的问题简单化、模块化、分离实现、解释执行。

总结

优点

解释器模式的优点是其灵活的扩展性,当我们想对文法规则进行扩展延伸时,只需要增加相应的非终结解释器,并在构建抽象语法树时,使用到新增的解释器对象进行具体的解释即可。

缺点

对于每一条文法都可以对应至少一个解释器,其会生成大量的类,导致后期维护困难;同时,对于过于复杂的文法,构建其抽象语法树会显得异常繁琐,甚至有可能会出现需要构建多棵抽象语法树的情况,因此,对于复杂的方法并不推荐使用解释器模式。





 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

peak wang

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值