Interpreter (interpreter) mode, which includes a grammatical representation with a composite hierarchical structure, where the rules are mapped to classes, and the expressions following the grammar can be converted into an abstract syntax tree, with no content other than the instance object graph of the composite schema.
A tree is an abstract noun, because in fact most of the time it is an expression of an abstract representation, it ignores the possibility of having a string or a concrete expression of a data structure (for example, in PHP, "A" and "\x41" are different representations of the same abstract literal), decoupling the results by logical rules , making the interpretation process much simpler.
The interpreter is not a very common pattern, but for simple syntax it adds a rule as easily as adding a class, but it does not solve the transformation from a concrete representation to an abstract syntax tree, which is done by other services.
The interpreter pattern is intended to be implemented using a composite hierarchy for a simple abstract expression (abstractexpression) method (interpreter operation), and the parameters of an interpreter operation are often collectively referred to as contexts, and for a given method they are usually replaced with computed values or they may not exist for some operations.
Similarly, when an interpreter is included, the leaf and container participant names of the composite pattern are different, reflecting the roles they play: non-terminal (terminal) or non-terminal (nonterminal) expressions.
Participants:
Client: Use an interpretation operation.
Abstract expression (abstractexpression): abstract based on an expression tree.
Non-non-terminal expression (nonterminalexpression): recursively contains expressions for other abstract expressions (Abstractexpression instances).
Non-terminal expression (terminalexpression): An expression that cannot be further simplified.
Design Patterns provides a sample extension for this pattern, and I'll replace the Boolean expression with a mathematical expression, so this example solves the presentation of a mathematical expression whose evaluate () is separated in a different concreteexpression class.
Copy Code code as follows:
/**
* Abstractexpression. All implementations to this interface
* are concreteexpressions.
*/
Interface Mathexpression
{
/**
* Calculates the value assumed by the expression.
* $values is passed to all expression but it
* is used by Variable. 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);
}
}
(A + 3)
$expression = new Product (new Literal), New Sum (New Variable (' A '), New Literal (3));
echo $expression->evaluate (Array (' A ' => 4)), "\ n";
Adding new rules to the grammar are easy:
E.g Power, subtraction ...
The composite, manipulation is even simpler:
We could add substitute ($letter, mathexpression $expr)
To the interface ...