Interpreter
Intent
Given a language, define a representation for its grammar along with
an interpreter that uses the representation to interpret sentences in
the language.
Problem
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".
Discussion
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.
Structure
Example
The Intepreter 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. [Michael Duell, "Non-software examples of software design
patterns", Object Magazine, Jul 97, p54]
Non-software example
Rules of thumb
Interpreter can use State to define parsing contexts. [GOF, p349]
The abstract syntax tree of Interpreter is a Composite (therefore
Iterator and Visitor are also applicable). [GOF, p255]
Terminal symbols within Interpreter's abstract syntax tree can
be shared with Flyweight. [GOF, p255]
C++ Demos | Java Demos
