|
| 1 | +# Interpreter Pattern |
| 2 | + |
| 3 | +Given a language, define a representation for its grammar along with an interpreter that users the representation to interpret sentences in the language. |
| 4 | + |
| 5 | +## Problem |
| 6 | + |
| 7 | +- Implementing many different search expressions directly into **one** class is inflexible because it is impossible to specify new expressions or change existing ones without having to change the class. |
| 8 | +- A grammar for a simple language should be defined so that sentences in the language can be interpreted. |
| 9 | + - `Note`: For complex languages, tools such as parser generators are a better alternative. |
| 10 | + |
| 11 | +## Solution |
| 12 | + |
| 13 | +- Define a grammar for a simple language by defining an `Expression` class hierarchy and implementing an `interpret()` operation. |
| 14 | +- Represent a sentence in the language by an abstract syntax tree (AST) made up of `Expression` instances. |
| 15 | +- Interpret a sentence by calling `interpret()` on the AST. |
| 16 | + |
| 17 | +## Common Structure |
| 18 | + |
| 19 | + |
| 20 | + |
| 21 | +* AbstractExpression (RegularExpression) |
| 22 | + * declares an abstract Interpret operation that is common to all nodes in the AST. |
| 23 | +* TerminalExpression (LiteralExpression) |
| 24 | + * implements an Interpret operation associated with terminal symbols in the grammar. |
| 25 | + * an instance is required for every terminal symbol in a sentence. |
| 26 | +* NonTerminalExpression (AlternationExpression, RepetitionExpressioni, SequenceExpression) |
| 27 | + * one such class is required for every rule `R ::= R1 R2 ... Rn` in the grammar |
| 28 | + * maintains instance variables of type AbstractExpression for each of the symbol R1 through Rn. |
| 29 | + * implements an Interpret operation for nonterminal symbols in the grammar. Interpret typically calls itself recursively on the variables representing R1 through Rn. |
| 30 | +* Context |
| 31 | + * contains information that's global to the interpreter |
| 32 | + |
| 33 | +## Collaboration |
| 34 | + |
| 35 | +* Client builds or is given an AST. Then the client initializes the context and invokes the `Interpret` operation. |
| 36 | +* The `Interpret` operations at each node use the context to store and access the state of the interpreter. |
| 37 | + |
| 38 | +## Benefits |
| 39 | + |
| 40 | +* *It's easy to change and extend the grammar.* |
| 41 | +* *Implementing the grammar is easy, too.* Classes defining nodes in the AST have similar implementations and they can be automated with a compiler or parser generator. |
| 42 | +* *Adding new ways to interpret expressions*. You can support pretty printing or type-checking an expression. |
| 43 | + * Consider using `Visitor` pattern, if you keep creating new ways of interpreting expression in order to avoid changing the grammar classes. |
| 44 | + |
| 45 | +## Drawbacks |
| 46 | + |
| 47 | +* *Complex grammars are hard to maintain.* The Interpreter pattern defines at least one class for every rule in the grammar. Hence grammars containing many rules can be hard to manage and maintain. |
| 48 | + |
| 49 | +## Example |
| 50 | + |
| 51 | +**Definition** |
| 52 | + |
| 53 | +**Usage** |
| 54 | + |
| 55 | +## Comparison with other patterns |
| 56 | + |
| 57 | +* **Composite** - The abstract syntax tree is an instance of the Composite pattern. |
| 58 | +* **Flyweight** - shows how to share terminal symbols within the AST. |
| 59 | +* **Iterator** - can be used to traverse the structure. |
| 60 | +* **Visitor** - can be used to maintain the behavior in each node in the AST in one class. |
0 commit comments