定義:給定一種語言,定義他的文法的一種表示,並定義一個解釋器,該解釋器使用該表示來解釋語言中句子。
類型:行為類模式
類圖:
解釋器模式是一個比較少用的模式,本人之前也沒有用過這個模式。下面我們就來一起看一下解釋器模式。
class Context {} abstract class Expression { public abstract Object interpreter(Context ctx); } class TerminalExpression extends Expression { public Object interpreter(Context ctx){ return null; } } class NonterminalExpression extends Expression { 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++){ //進行語法判斷,遞歸調用 } Expression exp = stack.pop(); exp.interpreter(ctx); } }
文法遞歸的代碼部分需要根據具體的情況來實現,因此在代碼中沒有體現。抽象表達式是生成語法集合的關鍵,每個非終結符表達式解釋一個最小的語法單元,然後通過遞歸的方式將這些語法單元組合成完整的文法,這就是解釋器模式。
解釋器是一個簡單的語法分析工具,它最顯著的優點就是擴展性,修改語法規則只需要修改相應的非終結符就可以了,若擴展語法,只需要增加非終結符類就可以了。
但是,解釋器模式會引起類的膨脹,每個語法都需要產生一個非終結符表達式,語法規則比較復雜時,就可能產生大量的類文件,為維護帶來非常多的麻煩。同時,由於采用遞歸調用方法,每個非終結符表達式只關心與自己相關的表達式,每個表達式需要知道最終的結果,必須通過遞歸方式,無論是面向對象的語言還是面向過程的語言,遞歸都是一個不推薦的方式。由於使用了大量的循環和遞歸,效率是一個不容忽視的問題。特別是用於解釋一個解析復雜、冗長的語法時,效率是難以忍受的。
在以下情況下可以使用解釋器模式:
解釋器模式真的是一個比較少用的模式,因為對它的維護實在是太麻煩了,想象一下,一坨一坨的非終結符解釋器,假如不是事先對文法的規則了如指掌,或者是文法特別簡單,則很難讀懂它的邏輯。解釋器模式在實際的系統開發中使用的很少,因為他會引起效率、性能以及維護等問題