设计模式--[7]解释器模式

来源：互联网发布：淘宝买家改评价怎么改编辑：程序博客网时间：2024/06/04 17:44

【工匠若水 http://blog.csdn.net/yanbober】阅读前一篇《设计模式(行为型)之访问者模式(Visitor Pattern)》http://blog.csdn.net/yanbober/article/details/45536787

概述

解释器模式是类的行为模式。给定一个语言之后，解释器模式可以定义出其文法的一种表示，并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子。

核心

概念：定义一个语言的文法，并且建立一个解释器来解释该语言中的句子，这里的“语言”是指使用规定格式和语法的代码。解释器模式是一种类行为型模式。

解释器模式结构重要核心模块：

抽象表达式(Expression)

声明一个所有的具体表达式角色都需要实现的抽象接口。这个接口主要是一个interpret()方法，称做解释操作。

终结符表达式(Terminal Expression)

实现了抽象表达式角色所要求的接口，主要是一个interpret()方法；文法中的每一个终结符都有一个具体终结表达式与之相对应。比如有一个简单的公式R=R1+R2，在里面R1和R2就是终结符，对应的解析R1和R2的解释器就是终结符表达式。

非终结符表达式(Nonterminal Expression)

文法中的每一条规则都需要一个具体的非终结符表达式，非终结符表达式一般是文法中的运算符或者其他关键字，比如公式R=R1+R2中，“+”就是非终结符，解析“+”的解释器就是一个非终结符表达式。

环境(Context)角色

这个角色的任务一般是用来存放文法中各个终结符所对应的具体值，比如R=R1+R2，我们给R1赋值100，给R2赋值200。这些信息需要存放到环境角色中，很多情况下我们使用Map来充当环境角色就足够了。

使用场景

有一个简单的语法规则，比如一个sql语句，如果我们需要根据sql语句进行rm转换，就可以使用解释器模式来对语句进行解释。

一些重复发生的问题，比如加减乘除四则运算，但是公式每次都不同，有时是a+b-c*d，有时是a*b+c-d等，公式千变万化，但是都是由加减乘除四个非终结符来连接的，这时我们就可以使用解释器模式。

解释器模式在实际的系统开发中使用的很少，因为他会引起效率、性能以及维护等问题。

程序猿实例

如下示例简单模拟了加减乘除整数算术运算操作，使用了解释器模式，不做过多操作解释：

package yanbober.github.io;import java.util.HashMap;import java.util.Map;//抽象表达式(Expression)interface Expression {    int interpret(Context context);}//终结符表达式(Terminal Expression)class Constant implements Expression {    private int i;    public Constant(int i) {        this.i = i;    }    @Override    public int interpret(Context context) {        return i;    }}class Variable implements Expression {    @Override    public int interpret(Context context) {        return context.LookupValue(this);    }}//非终结符表达式(Nonterminal Expression)class Add implements Expression {    private Expression left, right;    public Add(Expression left, Expression right) {        this.left = left;        this.right = right;    }    @Override    public int interpret(Context context) {        return left.interpret(context) + right.interpret(context);    }}class Sub implements Expression {    private Expression left, right;    public Sub(Expression left, Expression right) {        this.left = left;        this.right = right;    }    @Override    public int interpret(Context context) {        return left.interpret(context) - right.interpret(context);    }}class Mul implements Expression {    private Expression left, right;    public Mul(Expression left, Expression right) {        this.left = left;        this.right = right;    }    @Override    public int interpret(Context context) {        return left.interpret(context) * right.interpret(context);    }}class Div implements Expression {    private Expression left, right;    public Div(Expression left, Expression right) {        this.left = left;        this.right = right;    }    @Override    public int interpret(Context context) {        return left.interpret(context) / right.interpret(context);    }}//环境(Context)角色class Context {    private Map valueMap = new HashMap<>();    public void addValue(Variable x, int y) {        valueMap.put(x, y);    }    public int LookupValue(Variable x) {        return (int) valueMap.get(x);    }}//客户端public class Main {    public static void main(String[] args) {        //(a*b)/(a-b+15000)        Context context = new Context();        Variable a = new Variable();        Variable b = new Variable();        Constant c = new Constant(15000);        context.addValue(a, 14);        context.addValue(b, 10000);        Expression expression = new Div(new Mul(a, b), new Add(new Sub(a, b), c));        System.out.println("Result = "+expression.interpret(context));    }}1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114

总结一把

解释器模式优点：

易于改变和扩展文法。

每一条文法规则都可以表示为一个类，因此可以方便地实现一个简单的语言。

实现文法较为容易。在抽象语法树中每一个表达式节点类的实现方式都是相似的，这些类的代码编写都不会特别复杂，还可以通过一些工具自动生成节点类代码。

增加新的解释表达式较为方便。如果用户需要增加新的解释表达式只需要对应增加一个新的终结符表达式或非终结符表达式类，原有表达式类代码无须修改，符合“开闭原则”。

解释器模式缺点：

对于复杂文法难以维护。在解释器模式中，每一条规则至少需要定义一个类，因此如果一个语言包含太多文法规则，类的个数将会急剧增加，导致系统难以管理和维护，此时可以考虑使用语法分析程序等方式来取代解释器模式。

执行效率较低。由于在解释器模式中使用了大量的循环和递归调用，因此在解释较为复杂的句子时其速度很慢，而且代码的调试过程也比较麻烦。

【工匠若水 http://blog.csdn.net/yanbober】

0 0