解釋器模式是類的行為模式。給定一個語言之後，解釋器模式可以定義出其文法的一種表示，并同時提供一個解釋器。
作者QQ：1095737364 QQ群：123300273 歡迎加入！
1.模式定義:
解釋器模式是類的行為模式。給定一個語言之後，解釋器模式可以定義出其文法的一種表示，并同時提供一個解釋器。用戶端可以使用這個解釋器來解釋這個語言中的句子。
2.模式特點:
解釋器模式在實際的系統開發中使用的非常少，因為它會引起效率、性能以及維護等問題，一般在大中型的架構型項目能夠找到它的身影，比如一些資料分析工具、報表設計工具、科學計算工具等等，若你确實遇到“一種特定類型的問題發生的頻率足夠高”的情況，準備使用解釋器模式時，可以考慮一下Expression4J、MESP（Math Expression String Parser）、Jep等開源的解析工具包（這三個開源産品都可以百度、Google中搜尋到，請讀者自行查詢），功能都異常強大，而且非常容易使用，效率也還不錯，實作大多數的數學運算完全沒有問題
3.使用場景:
(1)有一個簡單的文法規則，比如一個sql語句，如果我們需要根據sql語句進行rm轉換，就可以使用解釋器模式來對語句進行解釋。
(2)一些重複發生的問題，比如加減乘除四則運算，但是公式每次都不同，有時是a+b-c*d，有時是a*b+c-d，等等等等個，公式千變萬化，但是都是由加減乘除四個非終結符來連接配接的，這時我們就可以使用解釋器模式。
(3)當有一個語言需要解釋執行，并且可以将該語言中的句子表示為一個抽象文法樹的時候，可以考慮使用解釋器模式。
(4)文法相對應該比較簡單，太複雜的文法不合适使用解釋器模式；
(5)效率要求不是很高，對效率要求很高的情況下,不适合使用解釋器模式。
(6)重複發生的問題可以使用解釋器模式,例如，多個應用伺服器，每天産生大量的日志，需要對日志檔案進行分析處理，由于各個伺服器的日志格式不同，但是資料要素是相同的，按照解釋器的說法就是終結符表達式都是相同的，但是非終結符表達式就需要制定了。在這種情況下，可以通過程式來一勞永逸地解決該問題。
4.模式實作:
下面就以一個示意性的系統為例，讨論解釋器模式的結構。系統的結構圖如下所示：
模式所涉及的角色如下所示：
(1)抽象表達式(Expression)角色：
聲明一個所有的具體表達式角色都需要實作的抽象接口。這個接口主要是一個interpret()方法，稱做解釋操作。
(2)終結符表達式(Terminal Expression)角色：
實作了抽象表達式角色所要求的接口，主要是一個interpret()方法；文法中的每一個終結符都有一個具體終結表達式與之相對應。比如有一個簡單的公式R=R1+R2，在裡面R1和R2就是終結符，對應的解析R1和R2的解釋器就是終結符表達式。
(3)非終結符表達式(Nonterminal Expression)角色：
文法中的每一條規則都需要一個具體的非終結符表達式，非終結符表達式一般是文法中的運算符或者其他關鍵字，比如公式R=R1+R2中，“+"就是非終結符，解析“+”的解釋器就是一個非終結符表達式。
(4)環境(Context)角色：
這個角色的任務一般是用來存放文法中各個終結符所對應的具體值，比如R=R1+R2，我們給R1指派100，給R2指派200。這些資訊需要存放到環境角色中，很多情況下我們使用Map來充當環境角色就足夠了。
為了說明解釋器模式的實作辦法，這裡給出一個最簡單的文法和對應的解釋器模式的實作，這就是模拟Java語言中對布爾表達式進行操作和求值。
在這個語言中終結符是布爾變量，也就是常量true和false。非終結符表達式包含運算符and，or和not等布爾表達式。這個簡單的文法如下：
Expression ::= Constant | Variable | Or | And | Not
And ::= Expression 'AND' Expression
Or ::= Expression 'OR' Expression
Not ::= 'NOT' Expression
Variable ::= 任何辨別符
Constant ::= 'true' | 'false'
解釋器模式的結構圖如下所示：
源代碼
[1]抽象表達式角色
public abstract class Expression {
/**
* 以環境為準，本方法解釋給定的任何一個表達式
*/
public abstract boolean interpret(Context ctx);
/**
* 檢驗兩個表達式在結構上是否相同
*/
public abstract boolean equals(Object obj);
/**
* 傳回表達式的hash code
*/
public abstract int hashCode();
/**
* 将表達式轉換成字元串
*/
public abstract String toString();
} [2]一個Constant對象代表一個布爾常量
public class Constant extends Expression{
private boolean value;
public Constant(boolean value){
this.value = value;
}
@Override
public boolean equals(Object obj) {
if(obj != null && obj instanceof Constant){
return this.value == ((Constant)obj).value;
}
return false;
}
@Override
public int hashCode() {
return this.toString().hashCode();
}
@Override
public boolean interpret(Context ctx) {
return value;
}
@Override
public String toString() {
return new Boolean(value).toString();
}
} [3]一個Variable對象代表一個有名變量
public class Variable extends Expression {
private String name;
public Variable(String name){
this.name = name;
}
@Override
public boolean equals(Object obj) {
if(obj != null && obj instanceof Variable)
{
return this.name.equals(
((Variable)obj).name);
}
return false;
}
@Override
public int hashCode() {
return this.toString().hashCode();
}
@Override
public String toString() {
return name;
}
@Override
public boolean interpret(Context ctx) {
return ctx.lookup(this);
}
} [4]代表邏輯“與”操作的And類，表示由兩個布爾表達式通過邏輯“與”操作給出一個新的布爾表達式的操作
public class And extends Expression {
private Expression left,right;
public And(Expression left , Expression right){
this.left = left;
this.right = right;
}
@Override
public boolean equals(Object obj) {
if(obj != null && obj instanceof And)
{
return left.equals(((And)obj).left) &&
right.equals(((And)obj).right);
}
return false;
}
@Override
public int hashCode() {
return this.toString().hashCode();
}
@Override
public boolean interpret(Context ctx) {
return left.interpret(ctx) && right.interpret(ctx);
}
@Override
public String toString() {
return "(" + left.toString() + " AND " + right.toString() + ")";
}
} [5]代表邏輯“或”操作的Or類，代表由兩個布爾表達式通過邏輯“或”操作給出一個新的布爾表達式的操作
public class Or extends Expression {
private Expression left,right;
public Or(Expression left , Expression right){
this.left = left;
this.right = right;
}
@Override
public boolean equals(Object obj) {
if(obj != null && obj instanceof Or)
{
return this.left.equals(((Or)obj).left) && this.right.equals(((Or)obj).right);
}
return false;
}
@Override
public int hashCode() {
return this.toString().hashCode();
}
@Override
public boolean interpret(Context ctx) {
return left.interpret(ctx) || right.interpret(ctx);
}
@Override
public String toString() {
return "(" + left.toString() + " OR " + right.toString() + ")";
}
} [6]代表邏輯“非”操作的Not類，代表由一個布爾表達式通過邏輯“非”操作給出一個新的布爾表達式的操作
public class Not extends Expression {
private Expression exp;
public Not(Expression exp){
this.exp = exp;
}
@Override
public boolean equals(Object obj) {
if(obj != null && obj instanceof Not)
{
return exp.equals(
((Not)obj).exp);
}
return false;
}
@Override
public int hashCode() {
return this.toString().hashCode();
}
@Override
public boolean interpret(Context ctx) {
return !exp.interpret(ctx);
}
@Override
public String toString() {
return "(Not " + exp.toString() + ")";
}
} [7]環境(Context)類定義出從變量到布爾值的一個映射
public class Context {
private Map<Variable,Boolean> map = new HashMap<Variable,Boolean>();
public void assign(Variable var , boolean value){
map.put(var, new Boolean(value));
}
public boolean lookup(Variable var) throws IllegalArgumentException{
Boolean value = map.get(var);
if(value == null){
throw new IllegalArgumentException();
}
return value.booleanValue();
}
} [8]用戶端類
public class Client {
public static void main(String[] args) {
Context ctx = new Context();
Variable x = new Variable("x");
Variable y = new Variable("y");
Constant c = new Constant(true);
ctx.assign(x, false);
ctx.assign(y, true);
Expression exp = new Or(new And(c,x) , new And(y,new Not(x)));
System.out.println("x=" + x.interpret(ctx));
System.out.println("y=" + y.interpret(ctx));
System.out.println(exp.toString() + "=" + exp.interpret(ctx));
}
} 運作結果如下：
5.優缺點:
(1)解釋器模式的優點
[1]易于實作文法：在解釋器模式中，一條文法規則用一個解釋器對象來解釋執行，對于解釋器的實作來講，功能就變得比較簡單，隻需要考慮這一條文法規則的實作就好了，其它的都不用管。
[2]易于擴充新的文法：正是由于采用一個解釋器對象負責一條文法規則的方式，使得擴充新的文法非常容易，擴充了新的文法，隻需要建立相應的解釋器對象，在建立抽象文法樹的時候使用這個新的解釋器對象就可以了。
(2)解釋器模式的缺點
[1]引起類膨脹：每個文法都要産生一個非終結符表達式，文法規則比較複雜時，就可能産生大量的類檔案，為維護帶來了非常多的麻煩。
[2]采用遞歸調用方法：每個非終結符表達式隻關心與自己有關的表達式，每個表達式需要知道最終的結果，必須一層一層地剝繭，無論是面向過程的語言還是面向對象的語言，遞歸都是在必要條件下使用的，它導緻調試非常複雜。想想看，如果要排查一個文法錯誤，我們是不是要一個一個斷點的調試下去，直到最小的文法單元。
[3]效率問題：解釋器模式由于使用了大量的循環和遞歸，效率是個不容忽視的問題，特别是用于解析複雜、冗長的文法時，效率是非常低的。
6.注意事項
盡量不要在重要的子產品中使用解釋器模式，否則維護會是一個很大的問題。在項目中可以使用shell、JRuby、Groovy等腳本語言來代替解釋器模式，彌補Java編譯型語言的不足。我們在一個銀行的分析型項目中就采用JRuby進行運算處理，避免使用解釋器模式的四則運算，效率和性能各方面表現良好。
解釋器模式真的是一個比較少用的模式，因為對它的維護實在是太麻煩了，想象一下，一坨一坨的非終結符解釋器，假如不是事先對文法的規則了如指掌，或者是文法特别簡單，則很難讀懂它的邏輯。解釋器模式在實際的系統開發中使用的很少，因為他會引起效率、性能以及維護等問題。