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

解释器模式的定义(现实项目中很少遇到,因此直接理论先。。。)

解释器模式是一种按照规定语法进行解析的方案,在现在项目中使用较少,其定义为:给定一门语言,定义它的方法的一种表示,并定义一个解释器,该解释器使用该表示来解释语言中的句子。其构成如下:

1、AbstractExpression——抽象解释器

具体的解释任务由各个实现类完成,具体的解释器分别由TerminalExpression和NonterminalExpression完成

2、TerminalExpression——终结符表达式

实现与方法中的元素相关联的解释操作,通过一个解释器模式中只有一个终结符表达式,但有多个实例,对应不同的终结符。

3、NonterminalExpression——非终结符表达式

文法中的每条规则对应于一个非终结表达式。非终结符表达式根据逻辑的复杂程序而增加,原则上每个文法规则对应一个非终结符表达式。

4、Context——环境角色

那现在用解释器模式来解释一下四则运算(加减乘除),类图如下:

图中MathExpression为抽象解释器,Literal、Variable为终结符表达式,Sum、Multiply为非终结符表达式,结构很清晰。实现代码如下:

<?php

interface MathExpression
{
    public function evaluate( array $values );
}

/**
 * A terminal expression which is a literal value.
 */
class Literal implements MathExpression
{
    private $_value;

    public function __construct( $value ) {
        $this->_value = $value;
    }

    public function evaluate( array $values ) {
        return $this->_value;
    }
}

/**
 * A terminal expression which represents a variable.
 */
class Variable implements MathExpression
{
    private $_letter;

    public function __construct( $letter ) {
        $this->_letter = $letter;
    }

    public function evaluate( array $values ) {
        return $values[$this->_letter];
    }
}

/**
 * Nonterminal expression.
 */
class Sum implements MathExpression
{
    private $_a;
    private $_b;

    public function __construct( MathExpression $a, MathExpression $b ) {
        $this->_a = $a;
        $this->_b = $b;
    }

    public function evaluate( array $values ) {
        return $this->_a->evaluate( $values ) + $this->_b->evaluate( $values );
    }
}

/**
 * Nonterminal expression.
 */
class Multiply implements MathExpression
{
    private $_a;
    private $_b;

    public function __construct( MathExpression $a, MathExpression $b ) {
        $this->_a = $a;
        $this->_b = $b;
    }

    public function evaluate( array $values ) {
        return $this->_a->evaluate( $values ) * $this->_b->evaluate( $values );
    }
}

// 10(a + 3)
$expression = new Multiply( new Literal( 10 ), new Sum( new Variable( 'a' ), new Literal( 3 ) ) );
echo $expression->evaluate( array( 'a' => 111 ) ), "\n";

运行结果:1140
[Finished in 0.1s]

我们来看看这么写的优缺点

解释器模式的优点

解释器模式是一个简单语法分析工具,它最显著的优点就是扩展性,修改语法规则只要修改相应的非终结符表达式就可以了,若扩展语法,则只要增加非终结符类就可以了。

解释器模式的缺点

1、解释器模式会引起类膨胀(感觉好多模式都有这个问题啊)

每个语法都要产生一个非终结符表达式,语法规则比较复杂时,就可以产生大量的类文件,为维护带来了非常多的麻烦。

2、解释器模式采用递归调用方法

每个终结符表达式只关心与自己有关的表达式,每个表达式需要知道最终的结果,必须一层一层地剥茧,无论是面向过程的语言还是面向对象的语言,递归都是在必要条件下使用的,它导致调试非常复杂。

3、效率问题

有递归自然就会有效率问题,特别是用于解释复杂冗长的语法时。

解释器模式的使用场景

1、重复发生的问题可以使用解释器模式

例如服务器日志的分析处理,由于各个服务器的日志模式不同,但是数据要素是相同的,按照解释器模式的说法就是终结符表达式都是相同的,但是非终结符表达式就需要制定了。

2、一个简单语法需要解释的场景

例如 SQL语法分析

解释器模式的注意事项

尽量不要在重要的模块中使用解释器模式,否则维护会是一个很大的问题。在项目中可以使用shell,JRuby,Groovy等脚本语言代替解释器模式,弥补php效率上的不足。

一般在大中型的框架型项目能够找到它的身影,如一些数据分析工具,报表设计工具,科学计算工具等,若你确实遇到“一种特定类型的问题发生的频率足够高”的情况,准备使用解释器模式时,可以考虑一下Expression4J,MESP,Jep等开源的解析工具包,功能都异常强大,没必要自己从头编写解释器。

时间: 2024-10-10 18:19:02

原始的解释器模式(Interpreter Pattern)的相关文章

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

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

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

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

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

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

设计模式之解释器模式(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; } 但是很明显,如果形式有限,那么可以针对对应的形式进行编程 如果

[设计模式-行为型]解释器模式(Interpreter)

一句话 看起来是用来解释一种语言的文法.(类似不同的解释器子类解释不同的字符) 和编译器类似的解释器, 实际状况可能使用的比较少. 概括 解析 INTERPRETER-俺有一个<泡MM真经>,上面有各种泡MM的攻略,比如说去吃西餐的步骤.去看电影的方法等等,跟MM约会时,只要做一个Interpreter,照着上面的脚本执行就可以了. 解释器模式:给定一个语言后,解释器模式可以定义出其文法的一种表示,并同时提供一个解释器.客户端可以使用这个解释器来解释这个语言中的句子.解释器模式将描述怎样在有了

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

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

解释器模式 Interpreter

代码例子 参考 1.解释器模式定义 给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子. 说明:解释器模式设计到文法规则和抽象语法树. 2.解释器模式的结构 解释器模式包含四个角色: 1)抽象表达式(AbstractExpress):声明抽象的解释操作,它是所有终结符表达式和非终结符表达式的公共父类. 2)终结符表达式(TerminalExpress):是抽象表达式的子类,实现了与文法中的终结符相关联的解释操作,句子中的每一个终结符都是该类的一个实例.

学习笔记——解释器模式Interpreter

解释器模式,其实就是编译原理中的语法解释器,如果用在项目中,可以用于实现动态脚本的解析,也就是说项目可以支持用户脚本扩展. 但实际上,这种运行时解释,效率很慢,如果不是很需要的话,不建议使用. 一种简单实现: Context是上下文场景,比如做一个计算器,那这个Context可以作为一个Calculator类,可以在构造函数中用于接受待解析的表达式(如 a+b-c),以及执行相应的解释. Expression代表不同的symbol的操作,比如: 1.+对应的Expression,操作是:将+的左