Interpreter Design Pattern And Detailing English Language Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Abstract:- The Interpreter pattern is used to model a grammar using a set of classes that represent possible expressions within the grammar. For instance, for the algebraic expression 4 + 4, an AddExpression class can be used to represent the expression. Included in the AddExpression class would be a reference to the two operands and the capacity to evaluate the expression and return a value based on the two operands.


The interpreter pattern is a Gang of Four design pattern. This is a behavioural pattern as it defines a manner for controlling communication between classes or entities. The interpreter pattern is used to define the grammar for instructions that form part of a language or notation, whilst allowing the grammar to be easily extended.

The interpreter pattern performs activities base upon a hierarchy of expressions. Each expression is terminal, meaning that it is a standalone structure that can be immediately evaluated, or non-terminal, meaning that it is composed of one or more expressions. The tree structure is similar to that defined by the composite design pattern, with terminal expressions being leaf objects and non-terminal expressions being composites. The tree contains the expressions to be evaluated and is usually generated by a parser. The parser itself is not a part of the interpreter pattern.

The interpreter design pattern is useful for simple languages where performance is not critical. As the grammar becomes more complex, the number of different expression types, each represented by its own class, can become unwieldy and lead to unmanageable class hierarchies. This can also slow the processing of the expressions. For these reasons, the pattern is considered to be inefficient and is rarely used. However, it should not be discounted for some situations.

An example of the use of the interpreter design pattern could be the processing of mathematical problems provided in a simplified Polish notation. This notation defines a mathematical operator followed by two values, for example "+ 5 6". In this case, the + symbol indicates that the two following values should be summed, giving 11. The notation allows multiple operators and values to be included in the string, for example "+ - 6 5 7". In this case, the subtraction would be applied to the 6 and 5 to give 1. The addition would then be applied to the calculated 1 and the 7 for a final result of 8. Polish notation is useful because it does not require the use of parentheses to avoid ambiguity.


Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.

Map a domain to a language, the language to a grammar, and the grammar to a hierarchical object-oriented design.


A class of problems occurs repeatedly in a well-defined and well-understood domain. If the domain were characterized with a "language", then problems could be easily solved with an interpretation "engine".


The Interpreter pattern discusses: defining a domain language (i.e. problem characterization) as a simple language grammar, representing domain rules as language sentences, and interpreting these sentences to solve the problem. The pattern uses a class to represent each grammar rule. And since grammars are usually hierarchical in structure, an inheritance hierarchy of rule classes maps nicely.

An abstract base class specifies the method interpret(). Each concrete subclass implements interpret() by accepting (as an argument) the current state of the language stream, and adding its contribution to the problem solving process.


The structure of the project follows the general structure of a parser in compiler terms. At a high level, a parser transforms a character sequence in a well-defined grammar into an intermediate data structure that can be evaluated at a later point while varying its input. At a lower level, the first step in the parsing process is to transform the character sequence into a token sequence. This step is called lexical analysis. The next step is to transform the token sequence into the intermediate data structure that can be evaluated.

The AXTokenizer class is responsible for transforming the initial character sequence into a token sequence. If the character sequence is not a valid token sequence, an exception is thrown. If the character sequence is a valid token sequence, the next step is general validation performed by the AXValidator class.

Once a valid token sequence is obtained, the ExpressionFactory is used to create a sequence ofExpression objects from the token sequence. The expression sequence is then evaluated by code in theAXParser class to produce an Expression object that represents the input algebraic expression by means of a tree of Expression objects. This expression tree is the intermediate data structure produced by the parser. The ExpressionContext class serves as the input to the expression tree and is passed down to the leaf expressions for evaluation by means of substitution.

Interpreter suggests modeling the domain with a recursive grammar. Each rule in the grammar is either a 'composite' (a rule that references other rules) or a terminal (a leaf node in a tree structure). Interpreter relies on the recursive traversal of the Composite pattern to interpret the 'sentences' it is asked to process.

The classes and/or objects participating in this pattern are:

AbstractExpression  (Expression):declares an interface for executing an operation

TerminalExpression  ( ThousandExpression, HundredExpression, TenExpression, OneExpression ):implements an Interpret operation associated with terminal symbols in the grammar.An instance is required for every terminal symbol in the sentence.

NonterminalExpression  ( not used ):one such class is required for every rule R ::= R1R2...Rn in the grammar.Maintains instance variables of type AbstractExpression for each of the symbols R1 through Rn.Implements an Interpret operation for nonterminal symbols in the grammar. Interpret typically calls itself recursively on the variables representing R1 through Rn.

Context  (Context):contains information that is global to the interpreter

Client  (InterpreterApp):builds (or is given) an abstract syntax tree representing a particular sentence in the language that the grammar defines. The abstract syntax tree is assembled from instances of the NonterminalExpression and TerminalExpression classes.I nvokes the Interpret operation.


The Interpreter pattern defines a grammatical representation for a language and an interpreter to interpret the grammar. Musicians are examples of Interpreters. The pitch of a sound and its duration can be represented in musical notation on a staff. This notation provides the language of music. Musicians playing the music from the score are able to reproduce the original pitch and duration of each sound represented.


1.Decide if a "little language" offers a justifiable return on investment.

2.Define a grammar for the language.

3.Map each production in the grammar to a class.

4.Organize the suite of classes into the structure of the Composite pattern.

5.Define an interpret(Context) method in the Composite hierarchy.

6.The Context object encapsulates the current state of the input and output as the former is parsed and the latter is accumulated. It is manipulated by each grammar class as the "interpreting" process transforms the input into the output.


a.Considered in its most general form (i.e. an operation distributed over a class hierarchy based on the Composite pattern), nearly every use of the Composite pattern will also contain the Interpreter pattern. But the Interpreter pattern should be reserved for those cases in which you want to think of this class hierarchy as defining a language.

b.Interpreter can use State to define parsing contexts.

c.The abstract syntax tree of Interpreter is a Composite (therefore Iterator and Visitor are also applicable).

d.Terminal symbols within Interpreter's abstract syntax tree can be shared with Flyweight.

e.The pattern doesn't address parsing. When the grammar is very complex, other techniques (such as a parser) are more appropriate.


The Interpreter design pattern not only adds overhead, it also gives you some additional possibilities. For example, imagine that the expression contains not only numbers and operators, but also variables. Expression value may vary according to values assigned to variables.

When using a traditional parser, the expression would have to be parsed each time the variables values are changed. With the Interpreter pattern, the situation is much more comfortable. Once the Abstract Syntax Tree is built, it may be reused many times. All you have to do is to provide the interpreter with up-to-date variables values. Remember - current conditions in which the interpreter is working (e.g. variables values) are called a context. Replace the context, keep the syntax tree and spare CPU cycles.


1.Specialized database query languages such as SQL.

2.Specialized computer languages which are often used to describe communication protocols.

3.Most general-purpose computer languages actually incorporate several specialized languages.


By using the Interpreter design pattern to parse RPN expressions, we didn't make a revolution. Take into account, though, that some applications of the Interpreter have made a big and well-deserved career. The Interpreter is being used to evaluate expressions written in highly specialized languages, like SQL (Structured Query Language).

I'm sure we all have encountered such situations in our programming career when expressing operations and dependencies in the programming language of your choice seemed unnatural and required writing similar code many times and spreading it across the source code.