Interpreter pattern


In computer programming, the interpreter pattern is a design pattern that specifies how to evaluate sentences in a language.
The basic idea is to have a class for each symbol in a specialized computer language. The syntax tree of a sentence in the language is an instance of the composite pattern and is used to evaluate the sentence for a client. See also Composite pattern.

Overview

The Interpreter
design pattern is one of the twenty-three well-known
GoF design patterns
that describe how to solve recurring design problems to design flexible and reusable object-oriented software, that is, objects that are easier to implement, change, test, and reuse.
What problems can the Interpreter design pattern solve?
When a problem occurs very often, it could be considered to represent it as a sentence in a simple language
so that an interpreter can solve the problem
by interpreting the sentence.
For example, when many different or complex search expressions must be specified.
Implementing them directly into a class is inflexible
because it commits the class to particular expressions and makes it impossible to specify new expressions or change existing ones independently from the class.
What solution does the Interpreter design pattern describe?
The expression objects are composed recursively into a composite/tree structure that is called
abstract syntax tree.
The Interpreter pattern doesn't describe how
to build an abstract syntax tree. This can
be done either manually by a client or automatically by a parser.
See also the UML class and object diagram below.

Uses

UML class and object diagram

In the above UML class diagram, the Client class refers to the common AbstractExpression interface for interpreting an expression
interpret.
The TerminalExpression class has no children and interprets an expression directly.
The NonTerminalExpression class maintains a container of child expressions
and forwards interpret requests
to these expressions.
The object collaboration diagram
shows the run-time interactions: The Client object sends an interpret request to the abstract syntax tree.
The request is forwarded to all objects downwards the tree structure.
The NonTerminalExpression objects forward the request to their child expressions.
The TerminalExpression objects perform the interpretation directly.

UML class diagram

Example

BNF

The following Backus–Naur form example illustrates the interpreter pattern. The grammar

expression ::= plus | minus | variable | number
plus ::= expression expression '+'
minus ::= expression expression '-'
variable ::= 'a' | 'b' | 'c' |... | 'z'
digit = '0' | '1' |... | '9'
number ::= digit | digit number

defines a language that contains Reverse Polish Notation expressions like:

a b +
a b c + -
a b + c a - -

C#

This structural code demonstrates the Interpreter patterns, which using a defined grammar, provides the interpreter that processes parsed statements.

namespace DesignPatterns.Interpreter

Java

Following the interpreter pattern, we need to implement the interface Expr with a lambda for each grammar rule.

public class Interpreter

PHP (Example 1)


/**
* AbstractExpression
*/
interface Expression


/**
* TerminalExpression
*/
class TerminalExpression implements Expression


/**
* NonTerminalExpression
*/
abstract class NonTerminalExpression implements Expression


/**
* NonTerminalExpression - PlusExpression
*/
class PlusExpression extends NonTerminalExpression


/**
* NonTerminalExpression - MinusExpression
*/
class MinusExpression extends NonTerminalExpression


/**
* Client
*/
class InterpreterClient


// test.php
function loadClass
spl_autoload_register;
)->main;
//result: -16

PHP (Example 2)

based on the example above with another realization of the Client

/**
* Client
*/
class InterpreterClient