深入分析PHP设计模式的解释器模式

解释器模式包括一个具有复合类层次结构的语法表示，规则映射到类，遵循语法的表达式可以转换成抽象语法树，它只有复合模式的实例对象图。Tree是一个抽象名词，因为其实很多时候它是一个抽象表达式，它忽略了可能有字符串或者数据结构的具体表达式(比如在PHP中，“a”和“\x41”是同一个抽象字面值的不同具体表达式)，通过逻辑规则将结果解耦，大大简化了解释过程。解释器不是一个很常见的模式，但是对于简单的语法来说，添加一个规则就像添加一个类一样容易，但是它并没有解决从具体表达式到抽象语法树的转换，这是由其他服务来完成的。解释器模式旨在为简单的抽象表达式方法(解释器操作)使用复合层次结构。解释器操作的参数一般称为上下文。对于给定的方法，它们通常被计算值替换，或者对于某些操作，它们可能不存在。类似地，当包含解释器时，复合模式的叶和容器参与者名称是不同的，这些名称反映了它们的角色：终端或非终端表达式。参与者：客户端：使用解释操作。抽象表达式：基于表达式树的抽象。非终结符表达式：递归包含其他抽象表达式(抽象表达式实例)的表达式。 TerminalExpression:无法进一步简化的表达式。

《设计模式》 一书针对这个模式提供了一个扩展示例，我将使用数学表达式替换布尔表达式重新改造了一下，因此这个例子解决了一个数学表达式的展现，它的评估()被分离在一个不同的混凝土表达式类中。复制代码代码如下：/** *抽象表达式。这个接口*的所有实现都是具体表达式。*/接口数学表达式{ /** *计算表达式假定的值。*请注意，$值被传递给所有表达式，但它*仅由变量使用。这是抽象树结构所必需的*/public function evaluate(array $ values)；} /** *是文字值的终端表达式*/class Literal实现MathExpression { private $ _ value public function _ _ construct($ value){ $ this-_ value=$ value；} public function evaluate(array $ values){ return $ this-_ value；} } /** *表示变量的终端表达式*/类变量实现MathExpression { private $ _ letter；public function _ _ construct($ letter){ $ this-_ letter=$ letter；} public function evaluate(array $ values){ return $ values[$ this-_ letter]；} } /** *非终结表达式总和.类实现了mathexpression { private $ _ a；private $ _ b；公共函数__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)；} } /** *非终结表达式产品类实现MathExpression { private $ _ a；private $ _ b；公共函数__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)$表达式=新产品(新文字(10)，新总和(新变量(' a ')，新字面(3)))；echo $ expression-evaluate(array(' a '=4))，' \ n '；//向语法中添加新规则很容易： //例如，幂、减法.//多亏了复合材料，操作变得更加简单： //我们可以在接口中添加替代的($letter，MathExpression $expr) //元素.