"Behavioral" interpreter mode

The interpreter pattern intends to define its grammatical representation for a given language, while defining a set of interpreters that the grammar represents to interpret the sentences in the language. The model is simple and popular, its main purpose is to explain the use of. As for what to explain, it depends on the specific context. We can write an interpreter for an expression, we can write an interpreter for a statement, a statement can be thought of as being composed of multiple expressions, so we can also write an interpreter for a piece of text, and so on. Before designing a valid interpreter, imagine that the first thing to do is to define its grammatical definition for the expression to be interpreted, namely: define its rules. A simple example, if the user himself invented a scripting language. If you want to make the language work, you must define various "rules" for it, such as what the keyword is, what the expression format is, how the statement is constructed, and if there is an object-oriented syntax, how the object is represented 、... And so on, and then you need to implement a compiler that recognizes these "rules" and can interpret and run them correctly.

The definition of each grammar is generally composed of many expressions. Complex expressions are also constructed from smaller expressions. For example: Expressions in C + +: (3 + 7) * 15; The expression can be disassembled as: expression One: (3 + 7); expression two: 15; and expression Three: result of expression one + expression two. Where expression two is the final non-split of the minimum granularity expression, called Terminator expression Terminalexpression. And the initial whole expression is a detachable, it is made up of other sub-expressions (in fact, if the example is more complex, then the effect may be better), called the non-terminator expression noterminalexpression. People who have learned the principles of compiling may know that the compiler (in fact, an interpreter) is generally the structure of a syntax tree, and that the leaves in this syntax tree are actually the expression two on this side, and the non-leaf is the expression on this side or the original whole expression. For a syntax tree of an arithmetic expression, in general, the leaf nodes are specific numeric values, and the nodes that connect these numeric values are generally arithmetic characters, such as: +-*/, and so on. The class structure diagram for the interpreter pattern is referenced below:

The pattern encoding structure is referenced as follows:

1 namespaceInterpreter2 {3     //Context4     classContext {};5 6     //an abstract expression7     classiabstractexpression8     {9      Public:Ten         //some code here ..... One         Virtual voidInterprete (context*PContext) {} A  -};//class Iabstractexpression -  the     classterminalexpression -     { -      Public: -         //some code here ..... +         Virtual voidInterprete (context* pContext) {/*some code here .....*/ } -  +};//class Terminalexpression A  at     classnoterminalexpression -     { -      Public: -         //some code here ..... -         Virtual voidInterprete (context* pContext) {/*some code here .....*/ } -  in};//class Noterminalexpression -  to}//namespace Interpreter

interpreter pattern Encoding structure Reference

Personal understanding, the model is quite complex and huge. Although its intent is simply to define a grammar and define its interpreter. And really want to design, its grain size will be very thin. Like a language, you need to define very, very many expressions. A Boolean requires a booleanexpression, a andexpression expression with an operation, a variable expression, a plus sign that requires an expression 、...、 and ultimately a composite expression that requires these simple expressions. In short, in order to be able to correctly explain the context, need to do all the preparation, but also need to be thorough analysis, otherwise, the granularity of the expression is not fine, the late reusability is insufficient; the granularity of the expression is too thin, then the design may be redundant. In addition, the interpreter mode, in fact, is very similar to the composite mode. Can even be seen as a special case of a composite pattern. Just the intent of the compound pattern is more general, representing a "partial-whole" relationship.

"Behavioral" interpreter mode