The Interpreter Design Pattern
The Interpreter pattern provides a way to evaluate language grammar or expressions for particular languages.
Use the Interpreter pattern when you have a language to interpret, and you can represent statements in the language as abstract syntax trees.
- TypeBehavioral
- Time ComplexityO(n) Linear Time – The time taken grows linearly with the size of the input. Examples include simple search algorithms.
- Efficiency4
-
Learning Effort
- Average7
- Conceptual9
- Debug and Maintain7
- Implementation7
- Prerequisites8
- Versatility6
Things you should know before you start
- Recursive Descent Parsing Understanding of recursive descent parsing, as the Interpreter pattern often involves recursion.
- Abstract Syntax Trees Understanding of abstract syntax trees, as they are often used in the implementation.
Minimal Example
Implementing a calculator that interprets and evaluates mathematical expressions.
class NumberExpression implements AbstractExpression {
interpret(context: string): number {
return parseInt(context, 10);
}
}
const expression = new NumberExpression();
const result = expression.interpret('5');
What’s happening in thie example
In this example, the `NumberExpression` class is a TerminalExpression that interprets numbers. The `clientCode` shows how to use this expression to interpret the number ‘5’.
How the Interpreter Works
The Interpreter pattern is used to define a representation for a language’s grammar and provides an interpreter to deal with this grammar.
This pattern is useful for parsing and interpreting code, queries, or complex expressions.
Entities in the Interpreter Design Pattern
-
AbstractExpressionThe AbstractExpression declares an abstract Interpret operation that all concrete expressions must implement.
- AbstractExpression has a one-to-many inherits relationship with TerminalExpression
- AbstractExpression has a one-to-many inherits relationship with NonTerminalExpression
What to watch out for when using or considering this design pattern.
Avoid using the Interpreter pattern for trivial expressions or languages, as it can add unnecessary complexity. Also, it’s not suitable for complex grammars.
Design patterns often confused with the Interpreter Design Pattern
The following design patterns are often confused with the Interpreter
for various resons.
If you’re exploring solutions, have a look through this list and see if
one of these might be a better fit for your problem.
-
Composite – The Composite pattern composes objects into tree structures to represent part-whole hierarchies.
The Composite pattern is similar to the Interpreter in the following ways.
- Both patterns can use tree structures.
- Both are useful for handling hierarchical data.
- Interpreter is used for interpreting languages, while Composite is used for handling tree structures in general.
- Interpreter often uses recursion for interpretation, while Composite may not.
-
Visitor – The Visitor pattern defines a new operation to a collection of objects without changing the objects themselves.
The Visitor pattern is similar to the Interpreter in the following ways.
- Both patterns can operate over a set of objects.
- Both can extend functionalities without changing existing code.
- Interpreter is specific to language interpretation, while Visitor is more general-purpose.
- Interpreter often involves parsing and may use recursion, while Visitor typically does not.