设计模式笔记-Interpreter解释器模式

这个模式讲真我理解不是很清楚，它的应用也是非常非常少，因为没用过，也不清楚它的应用场景。为了完结这一系列文章，还是把它写一写！

解释器嘛，对一个文法或表达式进行解释，好比编译系统对编程语言的解释，计算系统对计算模型的解释。举个列子，公司要对大数据进行处理，根据不同的需求，会建立很多不同的模型，a+b-c; a+b+c-e; a-b 等等。有人可能会想，我直接写计算表达式呗，有一个模型就写一个表达式，由程序解释并计算，当然可以，前提是模型比较少，并且基本固定不变。如果有成千上万个模型，你要写一万个if-else分支吗？这种做法相当于是写死了！好的办法是有一个解释程序，自动对输入的模型表达式进行识别，然后计算。

• 抽象解释器：声明一个所有具体表达式都要实现的抽象接口，接口中主要是一个interpret()方法，称为解释操作。具体解释任务由它的各个实现类来完成。
• 终结符表达式：实现与文法中的元素相关联的解释操作，终结符一半是文法中的运算单元，比如有一个简单的公式R=R1+R2，这里R1和R2就是终结符，对应的解析R1和R2的解释器就是终结符表达式。通常一个解释器模式中只有一个终结符表达式，但有多个实例，对应不同的终结符。根据它的这一特性，就可以采用享元模式保存它。
• 非终结符表达式：文法中的每条规则对应于一个非终结符表达式，非终结符表达式一般是文法中的运算符或者其他关键字，比如公式R=R1+R2中，+就是非终结符，解析+的解释器就是一个非终结符表达式。非终结符表达式根据逻辑的复杂程度而增加，原则上每个文法规则都对应一个非终结符表达式。这里只有+,-，如果加个乘和除的话，要另外派生出两个非终结符表达式的类，以表达乘、除的逻辑！
• 环境上下文：这个角色的任务一般是用来存放文法中各个终结符所对应的具体值，比如R=R1+R2，我们给R1赋值100，给R2赋值200。这些信息需要存放到环境角色中，很多情况下我们使用Map来充当环境角色就足够了。

上面这个加减运算的例子是比较简单的。既便是这些终结或非终结符的类都有了，还有根据逻辑来进行调用计算呢！+，-，x, /优先级啊，带括号啊，这些逻辑也挺复杂的。所以一个表达式，可能需要递归多次调用该模式的解释方法。直接贴个程序：

class Context
{
private:
	map<string, int> valueMap;

public:
	void addValue(string key, int value)
	{
		valueMap.insert(std::pair<string, int>(key, value));
	}

	int getValue(string key)
	{
		return valueMap[key];
	}
};

class AbstractExpression
{
public:
	virtual int interpreter(Context context) = 0;
};

class AddNonterminalExpression : public AbstractExpression
{
private:
	AbstractExpression *left;
	AbstractExpression *right;

public:
	AddNonterminalExpression(AbstractExpression *left, AbstractExpression *right)
	{
		this->left = left;
		this->right = right;
	}

	int interpreter(Context context)
	{
		return this->left->interpreter(context) + this->right->interpreter(context);
	}

};

class SubtractNonterminalExpression : public AbstractExpression
{
private:
	AbstractExpression *left;
	AbstractExpression *right;

public:
	SubtractNonterminalExpression(AbstractExpression *left, AbstractExpression *right)
	{
		this->left = left;
		this->right = right;
	}

	int interpreter(Context context)
	{
		return this->left->interpreter(context) - this->right->interpreter(context);
	}

};

class TerminalExpression : public AbstractExpression
{
private:
	int i;

public:
	TerminalExpression(int i)
	{
		this->i = i;
	}

	int interpreter(Context context)
	{
		return this->i;
	}
};

int main() {
	//a-b+c
	Context context;
	context.addValue("a", 7);
	context.addValue("b", 8);
	context.addValue("c", 2);

	SubtractNonterminalExpression *subtractValue = new SubtractNonterminalExpression(new TerminalExpression(
		context.getValue("a")), new TerminalExpression(context.getValue("b")));

	AddNonterminalExpression *addValue = new AddNonterminalExpression(subtractValue, new TerminalExpression(
		context.getValue("c")));

	cout << addValue->interpreter(context);

	return 0;
}

用户代码中，context中保存的变量就可以看成是一个模型里需要的所有变量，中间两行就是算法逻辑了：a-b+c，如果要换一个模型计算，这段逻辑用户自己要改写的，能自动识别模型表达式，可能要递归调用这些类方法，上面那种是不行的，它和你自己写a-b+c计算没区别。

解释器模式会引起类的膨胀，每个语法都需要产生一个非终结符表达式，语法规则比较复杂时，就可能产生大量的类文件，维护困难。使用递归会造成性能低下！