An in-depth analysis of the interpreter pattern of PHP design patterns

This article is a detailed analysis and introduction to the Interpreter pattern in PHPDesign Pattern. If you need it, please refer to the

Interpreter ) pattern, which consists of a representation of a grammar with a composite class hierarchy. Rules are mapped to classes. The expressions following the grammar can be converted into an abstract syntax tree, except for instances of the composite pattern. There is nothing other than the object graph.

Tree is an abstract noun, because in fact most of the time it is an abstract representation of an expression. It ignores that there may be a string or a data structure. Concrete expressions (for example, in PHP, "A" and "\x41" are different concrete manifestations of the same abstract literal value) decouple the results through logical rules, greatly simplifying the interpretation process.

Interpreter is not a very common pattern, but for simple syntax, it is as easy to add a rule as adding a class, but it does not solve the conversion from concrete representation to abstract syntax tree, which is Completed by other services.

The interpreter pattern is designed to leverage a composite hierarchical structure for a simple AbstractExpression method (interpreter operation). The parameters of the interpreter operation are usually collectively called the context. For a given of a method, they are often replaced by computed values, or they may not exist for some operations.

Also, when an interpreter is included, the leaf and container participant names of the composite pattern will be different, and these names reflect the role they play: terminal or non-terminal (nonterminal) expression.

Participants:
◆Client: Use explain operation.
◆Abstract Expression: Abstract based on an expression tree.
◆NonTerminalExpression: An expression that recursively contains other abstract expressions (AbstractExpression instances).
◆Terminal Expression: An expression that cannot be further simplified.


The book "Design Patterns" provides an extended example for this pattern. I remodeled it by replacing the Boolean expression with a mathematical expression, so this example solves a mathematical expression. expression, its evaluate() is separated into a different ConcreteExpression class.

The code is as follows:

/**  
 * AbstractExpression. All implementations of this interface  
 * are ConcreteExpressions.  
 */ 
interface MathExpression  
{  
    /**  
     * Calculates the value assumed by the expression.  
     * Note that $values is passed to all expression but it  
     * is used by Variable only. This is required to abstract  
     * away the tree structure.  
     */ 
    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 Product 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 Product(new Literal(10), new Sum(new Variable('a'), new Literal(3)));  
echo $expression->evaluate(array('a' => 4)), "\n";  
// adding new rules to the grammar is easy:  
// e.g. Power, Subtraction...  
// thanks to the Composite, manipulation is even simpler:  
// we could add substitute($letter, MathExpression $expr)  
// to the interface...

The above is the detailed content of An in-depth analysis of the interpreter pattern of PHP design patterns. For more information, please follow other related articles on the PHP Chinese website!