解释器模式——化繁为简

(《设计模式解析与实战——何红辉,关爱民》读书笔记)

推荐一篇博客:史上最全设计模式导学目录(完整版)
http://blog.csdn.net/lovelion/article/details/17517213

这种模式并不多见,因为我们平时不需要去创造一条语法规则。所以对于大部分人来说,只需要知道其思想即可。

一、定义
给定一个语言,定义它的文法的一种表示,并定义一个解释器,该解释器使用该表示来解释语言中的句子。
比如,给定一个语言(汉语),定义它的一种文法(主谓宾),然后定义一个解释器(翻译机,用来翻译汉语)。在计算机中,计算机可以实现四则运算,其实是利用解释器模型将+、—、*、/翻译成计算机可以理解的语言,然后按照特定规则运算。

二、使用场景
(1)如果某个简单的语言需要解释执行而且可以将该语言中的语句表示为一个抽象语法树时可以考虑使用解释器模式。
(2)在某些特定的领域出现不断重复的问题时,可以将该领域的问题转化为一种语法规则下的语句,然后构建解释器来解释该语句。

三、解释器模式的通用模式代码

/**
 * 抽象表达式:声明一个抽象的解释操作父类
 */
public abstract class AbstractExpression {
    /**
     * 抽象的解析方法
     * 
     * @param context
     *            上下文环境对象
     */
    public abstract void interpret(Context context);
}
/**
 * 终结符表达式
 */
public class TerminalExpression extends AbstractExpression {

    @Override
    public void interpret(Context context) {
        // 实现文法中与终结符有关的解释操作
    }
}
/**
 * 非终结符表达式
 */
public class NonterminaExpression extends AbstractExpression {

    @Override
    public void interpret(Context context) {
        // 实现文法中与非终结符有关的解释操作
    }
}
/**
 * 上下文环境类 包含解释器之外的全局信息
 */
public class Context {

}
/**
 * 客户类
 */
public class Client {
    public static void main(String[] args) {
        // 根据文法对特定句子构建抽象语法树后解释
    }
}

四、总结
优点:
灵活的扩展性,当需要对文法规则进行扩展延伸时,只需要增加相应的非终结符解释器,并在构建抽象语法时,使用到新增的解释器对象进行具体的解释即可,非常方便。
缺点:
(1)对于每一条文法都可以对应至少一个解释器,其会生成大量的类,导致后期维护困难;
(2)对于复杂的文法,构建其抽象语法树会显得异常繁琐,甚至有可能会出现需要多颗抽象语法树的情况,因此,对于复杂的文法并不推荐使用解释器模式。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值