原始的解释器模式(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、反复发生的问题能够使用解释器模式
比如server日志的分析处理,因为各个server的日志模式不同。可是数据要素是同样的,依照解释器模式的说法就是终结符表达式都是同样的,可是非终结符表达式就须要制定了。
2、一个简单语法须要解释的场景
比如 SQL语法分析
解释器模式的注意事项
尽量不要在重要的模块中使用解释器模式,否则维护会是一个非常大的问题。在项目中能够使用shell,JRuby,Groovy等脚本语言取代解释器模式,弥补php效率上的不足。
一般在大中型的框架型项目可以找到它的身影,如一些数据分析工具。报表设计工具,科学计算工具等。若你确实遇到“一种特定类型的问题发生的频率足够高”的情况,准备使用解释器模式时,可以考虑一下Expression4J,MESP,Jep等开源的解析工具包,功能都异常强大,不是必需自己从头编写解释器。
最新文章
- 构建ASP.NET MVC4+EF5+EasyUI+Unity2.x注入的后台管理系统(24)-权限管理系统-将权限授权给角色
- 学习Git的总结与体会
- 迅雷VIP帐号获取小工具
- 算法训练 Hankson的趣味题
- AM3359之U-boot及kernel编译
- MySql经典语句
- 【VC】VC工具栏图标合并工具(非tbcreator和visual toolbar)
- C++里的int 和string类型相互转换
- Linux 系统下查看硬件信息命令大全
- URL传值中文乱码
- nginx grok 正则错误的输出情况
- AsyncTask的用法总结
- ModelBinder——ASP.NET MVC Model绑定的核心
- C#入门经典第六章函数-2-委托
- 从has no method &#39;tmpl&#39;谈起
- node传统读取文件和promise,async await,
- ThetaSome_ThetaAll子查询
- JDBC API 事务的实践
- 机器学习基础一(TP,TN,FP,FN等)
- Ball CodeForces - 12D (线段树)