23 Design Modes (14): Interpreter mode

Definition: Given a language that defines a representation of his grammar and defines an interpreter that uses that representation to interpret sentences in a language.

Type: Behavior class pattern.

Class Diagram:

Interpreter mode is a less-used mode, I have not used this mode before. Let's take a look at the interpreter mode.

Structure of the Interpreter pattern:

Abstract Interpreter: Declares an abstract interface (or abstract class) to be implemented by all concrete expressions, which is primarily a interpret () method, called an interpretation operation. The specific interpretation task is done by its various implementation classes, and the specific interpreter is nonterminalexpression by the Terminator interpreter Terminalexpression and the non-terminator interpreter.

Terminator expression: Implements an interpreted operation associated with an element in the grammar, usually with only one terminator expression in an interpreter pattern, but with multiple instances that correspond to different terminators. Terminator is half the arithmetic unit in grammar, for example, there is a simple formula R=R1+R2, in which R1 and R2 are terminator, the corresponding parsing R1 and R2 interpreter is the Terminator expression.

Non-terminator expression: each rule in the grammar corresponds to a non-terminator expression, the non-terminator expression is generally the operator in the grammar or other keywords, such as the formula R=R1+R2, + is non-terminator, parsing + interpreter is a non-terminator expression. The non-terminator expression increases according to the complexity of the logic, in principle each grammar rule corresponds to a non-terminator expression.

Environment role: The task of this role is generally used to store the grammar of each terminator corresponding to the specific values, such as R=R1+R2, we give R1 value 100, to R2 assignment value 200. This information needs to be stored in the environment role, and in many cases it is sufficient for us to use map to act as an environment role.

Code implementation:

ClassContext {}AbstractClassExpression {PublicAbstract Object Interpreter (Context CTX); }ClassTerminalexpressionExtendsExpression {Public Object Interpreter (Context ctx) {ReturnNull } }ClassNonterminalexpressionExtendsexpression {public nonterminalexpression (Expression ... expressions) {} public Object Interpreter (Context ctx) {return null;} } public class client {public static void Main ( String[] (args) {String expression = ""; char[] Chararray = Expression.tochararray (); Context ctx = new Context (); stack<expression> stack = new stack<expression> (); for (int i=0;i<chararray.length;i++) { //for syntax judgment, recursive invocation} Expression exp = Stack.pop (); Exp.interpreter (CTX); } }

The code part of the grammatical recursion needs to be implemented according to the specific situation, so it is not reflected in the code. Abstract expressions are the key to generating a collection of grammars, and each non-terminator expression interprets a minimal unit of syntax and then recursively combines the grammatical units into a complete grammar, which is the interpreter pattern.

The pros and cons of the interpreter pattern:

Interpreter is a simple parsing tool, its most significant advantage is extensibility, modify the grammar rules only need to modify the corresponding non-terminator, if the extension of the syntax, only need to increase the non-Terminator class.

However, the interpreter pattern causes the class to swell, each syntax needs to produce a non-terminator expression, and when the syntax rules are complex, it is possible to generate a large number of class files, which can cause a lot of trouble for maintenance. At the same time, because of the recursive invocation method, each non-terminator expression only cares about its own expression, each expression needs to know the final result, must be recursive, whether it is object-oriented language or process-oriented language, recursion is a non-recommended way. As a result of the use of a large number of loops and recursion, efficiency is a problem that cannot be neglected. Especially when it comes to interpreting a complex, lengthy grammar, efficiency is intolerable.

Application scenarios for the interpreter pattern:

You can use the interpreter mode in the following situations:

There is a simple syntax rule, such as an SQL statement, that can be interpreted using the interpreter pattern if we need to make RM conversions based on SQL statements.

Some recurring problems, such as subtraction arithmetic, but the formula is different every time, sometimes a+b-cD, sometimes ab+c-d, and so on, and so on, the formula is changeable, but all are from subtraction four non-terminator to connect, then we can use the interpreter mode.

Precautions:

Interpreter mode is really a less used mode, because it is very difficult to maintain, imagine, a lump of non-terminator interpreter, if not in advance of the rules of grammar, or grammar is particularly simple, it is hard to read its logic. The interpreter pattern is rarely used in real-world system development because he can cause problems such as efficiency, performance, and maintenance.

23 Design Modes (14): Interpreter mode