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

Posted it-deepinmind

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了原始的解释器模式(Interpreter Pattern)相关的知识,希望对你有一定的参考价值。

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

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

1、AbstractExpression——抽象解释器

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

2、TerminalExpression——终结符表达式

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

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

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

4、Context——环境角色

 

 

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

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

php代码:

<?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 ) ), "
";  
  
运行结果:1140  
[Finished in 0.1s]  

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

解释器模式的优点

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

 

解释器模式的缺点

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

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

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

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

3、效率问题

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

 

 

解释器模式的使用场景

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

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

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

例如 SQL语法分析

 

 

解释器模式的注意事项

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

 

 

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

 

转载于:https://www.iteye.com/blog/lobert-2065604

 

以上是关于原始的解释器模式(Interpreter Pattern)的主要内容,如果未能解决你的问题,请参考以下文章

精读《设计模式 - Interpreter 解释器模式》

解释器模式 (Interpreter Pattern)

Behavioral模式之Interpreter模式

解释器模式(Interpreter Pattern)

设计模式---领域规则模式之解析器模式(Interpreter)

解释器模式(Interpreter)