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

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

其构成例如以下：

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 = http://www.mamicode.com/$value;"\n";

执行结果：1140
[Finished in 0.1s]

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

解释器模式的长处

解释器模式是一个简单语法分析工具，它最显著的长处就是扩展性。改动语法规则仅仅要改动对应的非终结符表达式就能够了，若扩展语法，则仅仅要添加非终结符类就能够了。

解释器模式的缺点

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

每一个语法都要产生一个非终结符表达式，语法规则比較复杂时，就能够产生大量的类文件，为维护带来了许多的麻烦。

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

每一个终结符表达式仅仅关心与自己有关的表达式，每一个表达式须要知道终于的结果。必须一层一层地剥茧。不管是面向过程的语言还是面向对象的语言，递归都是在必要条件下使用的，它导致调试很复杂。

3、效率问题

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

解释器模式的使用场景

1、反复发生的问题能够使用解释器模式

比如server日志的分析处理，因为各个server的日志模式不同。可是数据要素是同样的，依照解释器模式的说法就是终结符表达式都是同样的，可是非终结符表达式就须要制定了。

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

比如 SQL语法分析

解释器模式的注意事项

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

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