浅谈设计模式:解释器模式(Interpreter Pattern)

热爱生活、享受娱乐、专注技术,欢迎关注微信公众号QGer,我们一起见证成长!

什么是解释器模式?

官方解释:to define a representation of grammar of a given language, along with an interpreter that uses this representation to interpret sentences in the language。

定义一个给定语言的语法表达式,并用该表达式作为一个解释器来解释语言中的句子。

通俗解释:给定一种语言及相关语法,根据这些语法定义一个语法表达式的解释器,客户端可以使用这个解释器来解释这个语言中句子。

为什么使用解释器模式?

  • 语法表达式进行抽象封装,易于修改及拓展,当这个语言新增了某种特性,可以通过继承抽象表达式类来实现新的语言特性。
  • 每一条语法都可以表示为一个表达式类,实现起来比较容易。

PS:该模式由于其结构特性,对于复杂语法很难维护,执行效率比较低,因此实际开发中几乎不适用这个模式,但是其本身的结构以及思想还是可以学习借鉴一下的。

如何使用解释器模式?

UML图如下:

各个组件解释:

  • AbstractExpression(抽象表达式):声明一个抽象的解释操作interpreter,这个接口为所有具体表达式角色(抽象语法树中的节点)都要实现的。
  • TerminalExpression(终结表达式):实现了抽象表达式角色所要求的接口,主要是一个interpret()方法;文法中的每一个终结符都有一个具体终结表达式与之相对应。比如有一个简单的公式R=R1+R2,在里面R1和R2就是终结符,对应的解析R1和R2的解释器就是终结符表达式。
  • NonTerminalExpression(非终结表达式):文法中的每一条规则都需要一个具体的非终结符表达式,非终结符表达式一般是文法中的运算符或者其他关键字,比如公式R=R1+R2中,“+”就是非终结符,解析“+”的解释器就是一个非终结符表达式。
  • Client(客户端):使用解释器的角色。
  • Context(上下文):这个角色的任务一般是用来存放文法中各个终结符所对应的具体值,比如R=R1+R2,我们给R1赋值100,给R2赋值200。这些信息需要存放到环境角色中,很多情况下我们使用一个映射(Map)来充当环境角色就足够了。

应用实例:

有这么一个简单的需求,给予一个字符,让你判断是否是数字字符(‘0’-‘9’),可以这么实现:

1、定义一个抽象表达式

interface AbstractExpression {
    boolean interpret(Character character);
}

2、定义终结表达式,即直接判断字符是否是数字字符

public class TerminalExpression implements AbstractExpression {
    @Override
    public boolean interpret(Character character) {
        //是否是数字字符
        return character.isDigit(character);
    }
}

3、定义简单的非终结表达式,and 、not 、or

public class AndExpression implements AbstractExpression {
    private AbstractExpression leftExpression;
    private AbstractExpression rightExpression;

    public AndExpression(AbstractExpression leftExpression, AbstractExpression rightExpression) {
        this.leftExpression = leftExpression;
        this.rightExpression = rightExpression;
    }

    @Override
    public boolean interpret(Character character) {
        return leftExpression.interpret(character) && rightExpression.interpret(character);
    }
}

public class NotExpression implements AbstractExpression {
    private AbstractExpression expression;

    public NotExpression(AbstractExpression expression) {
        this.expression = expression;
    }

    @Override
    public boolean interpret(Character character) {
        return !expression.interpret(character);
    }
}

public class OrExpression implements AbstractExpression {
    private AbstractExpression leftExpression;
    private AbstractExpression rightExpression;

    public OrExpression(AbstractExpression leftExpression, AbstractExpression rightExpression) {
        this.leftExpression = leftExpression;
        this.rightExpression = rightExpression;
    }

    @Override
    public boolean interpret(Character character) {
        return leftExpression.interpret(character) || rightExpression.interpret(character);
    }
}

4、客户端使用,这里由于相对简单,不需要使用context组件:

public class Client {
    public static void main(String[] args) {
        Character digitCharacter = new Character(‘1‘);
        Character notdigitCharacter = new Character(‘l‘);
        AbstractExpression terminalExpression = new TerminalExpression();
        AbstractExpression notExpression = new NotExpression(terminalExpression);
        AbstractExpression andExpression = new AndExpression(terminalExpression, notExpression);
        AbstractExpression orExpression = new OrExpression(terminalExpression, notExpression);

        System.out.println(andExpression.interpret(digitCharacter));
        System.out.println(andExpression.interpret(notdigitCharacter));
        System.out.println(orExpression.interpret(digitCharacter));
        System.out.println(orExpression.interpret(notdigitCharacter));
    }
}
时间: 2024-11-05 16:32:18

浅谈设计模式:解释器模式(Interpreter Pattern)的相关文章

C#设计模式:解释器模式(Interpreter Pattern)

一,C#设计模式:解释器模式(Interpreter Pattern) 1,解释器模式的应用场合是Interpreter模式应用中的难点,只有满足“业务规则频繁变化,且类似的模式不断重复出现,并且容易抽象为语法规则的问题”才适合使用解释器模式2,解释器设计模式每个解释的类有自己的规则,并且与其他业务规则不冲突 二,如下代码 using System; using System.Collections.Generic; using System.Linq; using System.Text; u

二十四种设计模式:解释器模式(Interpreter Pattern)

解释器模式(Interpreter Pattern) 介绍给定一个语言, 定义它的文法的一种表示,并定义一个解释器,该解释器使用该表示来解释语言中的句子. 示例有一个Message实体类,某个类对它的操作有Get()方法.现在要求用具有某一规则的中文语法来执行这个操作. MessageModel using System; using System.Collections.Generic; using System.Text; namespace Pattern.Interpreter { //

设计模式(行为型)之解释器模式(Interpreter Pattern)

PS一句:最终还是选择CSDN来整理发表这几年的知识点,该文章平行迁移到CSDN.因为CSDN也支持MarkDown语法了,牛逼啊! [工匠若水 http://blog.csdn.net/yanbober] 阅读前一篇<设计模式(行为型)之访问者模式(Visitor Pattern)>http://blog.csdn.net/yanbober/article/details/45536787 概述 解释器模式是类的行为模式.给定一个语言之后,解释器模式可以定义出其文法的一种表示,并同时提供一个

[设计模式] 解释器模式 Interpreter

在GOF的<设计模式:可复用面向对象软件的基础>一书中对解释器模式是这样说的:给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子.如果一种特定类型的问题发生的频率足够高,那么可能就值得将该问题的各个实例表述为一个简单语言中的句子.这样就可以构建一个解释器,该解释器通过解释这些句子来解决该问题. 就如上面说的那个游戏,我输入up walk 5,我必须按照:移动方向+移动方式+移动距离这种格式输入我的指令,而这种格式的指令就是一种文法,只有按照了我定义的

原始的解释器模式(Interpreter Pattern)

解释器模式的定义(现实项目中很少遇到,因此直接理论先...) 解释器模式是一种按照规定语法进行解析的方案,在现在项目中使用较少,其定义为:给定一门语言,定义它的方法的一种表示,并定义一个解释器,该解释器使用该表示来解释语言中的句子.其构成如下: 1.AbstractExpression--抽象解释器 具体的解释任务由各个实现类完成,具体的解释器分别由TerminalExpression和NonterminalExpression完成 2.TerminalExpression--终结符表达式 实现

深入浅出设计模式——解释器模式(Interpreter Pattern)

模式动机 如果在系统中某一特定类型的问题发生的频率很高,此时可以考虑将这些问题的实例表述为一个语言中的句子,因此可以构建一个解释器,该解释器通过解释这些句子来解决这些问题.解释器模式描述了如何构成一个简单的语言解释器,主要应用在使用面向对象语言开发的编译器中. 模式定义解释器模式(Interpreter Pattern) :定义语言的文法,并且建立一个解释器来解释该语言中的句子,这里的“语言”意思是使用规定格式和语法的代码,它是一种类行为型模式.Interpreter Pattern: Give

浅谈设计模式1-策略模式

对于大多数面向对象的初学者来说,将思维模式从面向过程转变过来是一个比较困难的过程.很多人在用面向对象语言编写程序的时候,依然会感觉自己在用面向过程的思维,笔者分享这篇文章的用意便是希望可以对大家有一些积极的影响. 阅读本文可以是没有接触设计模式,但需要一定的面向对象基础,至少简单理解封装,继承多态. 对于刚开始接触设计模式来说,一开始就说概念性的东西,很少能够理解.所以我们可以先跳过这些,通过一个小的程序场景来进行一个比较直观的认识. 模拟魂斗罗发射子&弹 相信大家小的时候玩过一款叫魂斗罗的游戏

浅谈设计模式3-模板方法模式

模版方法模式,个人认为还是用处比较多的一个设计模式,而且也是比较好学和理解的一个.依然来通过模拟一个场景来慢慢了解. 现在我们来实现一下泡茶这个过程.首先我们需要烧开一壶水,然后往茶壶中放茶叶,加入开水,等待茶泡好. 经过前两次的分享,大家应该具备了基本的面向对象的思想了,这里就不再用面向过程的方式演示了. 首先,有一种普通人,他泡茶的方式是这样的 public class Common     { public void MakeTea()         {             Heat

设计模式之解释器模式(Interpreter)摘录

23种GOF设计模式一般分为三大类:创建型模式.结构型模式.行为模式. 创建型模式抽象了实例化过程,它们帮助一个系统独立于如何创建.组合和表示它的那些对象.一个类创建型模式使用继承改变被实例化的类,而一个对象创建型模式将实例化委托给另一个对象.创建型模式有两个不断出现的主旋律.第一,它们都将关于该系统使用哪些具体的类的信息封装起来.第二,它们隐藏了这些类的实例是如何被创建和放在一起的.整个系统关于这些对象所知道的是由抽象类所定义的接口.因此,创建型模式在什么被创建,谁创建它,它是怎样被创建的,以

解释器模式 Interpreter 行为型 设计模式(十九)

解释器模式(Interpreter) 考虑上图中计算器的例子 设计可以用于计算加减运算(简单起见,省略乘除),你会怎么做? 你可能会定义一个工具类,工具类中有N多静态方法 比如定义了两个方法用于计算a+b 和 a+b-c public static int add(int a,int b){ return a+b; } public static int add(int a,int b,int c){ return a+b-c; } 但是很明显,如果形式有限,那么可以针对对应的形式进行编程 如果