標簽： 設(shè)計模式初涉
描述性文字
解釋器模式是一個用的比較少的設(shè)計模式，而且不太好理解，先說下概念相關(guān)的東西
再寫個代碼示例幫助下理解：
定義
給定一個語言之后，解釋器模式可以定義出其文法的一種表示，并同時提供一個
解釋器，客戶端可以使用這個解釋器來解釋這個語言中的句子。
四個角色
AbstractExpression：抽象表達式，聲明一個所有具體表達式都要實現(xiàn)的接口，
接口中主要是一個interpret()方法，稱為解釋操作，具體的解釋任務(wù)由他的各個實現(xiàn)
類來完成，而具體的解釋器又分別由 終結(jié)符解釋器 與 非終結(jié)符解釋器 完成。TerminalExpression：終結(jié)符表達式，實現(xiàn)與文法中的元素相關(guān)聯(lián)的解釋操作，
通常一個解釋器模式中只有一個終結(jié)符表達式，但有多個實例，對應(yīng)不同的終結(jié)符。、
終結(jié)符一半是文法中的運算單元，比如有一個簡單的公式R=R1+R2，在里面R1和R2就是終結(jié)符，
對應(yīng)的解析R1和R2的解釋器就是終結(jié)符表達式。NonterminalExpression ：非終結(jié)符表達式，文法中的每條規(guī)則對應(yīng)于一個非終
結(jié)符表達式，非終結(jié)符表達式一般是文法中的運算符或者其他關(guān)鍵字，比如公式R=R1+R2中，
+就是非終結(jié)符，解析+的解釋器就是一個非終結(jié)符表達式。非終結(jié)符表達式根據(jù)邏輯的復雜
程度而增加，原則上每個文法規(guī)則都對應(yīng)一個非終結(jié)符表達式。Context：上下文環(huán)境，存放文法中各個終結(jié)符所對應(yīng)的具體值，比如R=R1+R2，我們
給R1賦值100，給R2賦值200。這些信息需要存放到環(huán)境角色中，很多情況下我們使用Map來充
當環(huán)境角色就足夠了。
UML類圖
優(yōu)缺點
優(yōu)點
- 1.易于實現(xiàn)簡易語法，一條語法規(guī)則用一個解釋器對象解釋執(zhí)行
- 2.易于擴展新的語法，只需創(chuàng)建相應(yīng)的解釋器對象，在創(chuàng)建抽象語法樹的時候使用即可。
- 3.增加了新的解釋表達式的方式
缺點
- 1.可使用場景較少
- 2.對于復雜的文法比較難維護
- 3.引起類膨脹
- 4.采用遞歸調(diào)用方法，效率，性能，維護問題
使用場景
- 1.重復發(fā)生的問題
- 2.一個簡單語法需要解釋的場景
- 3.將一個解釋執(zhí)行的語言中的句子表示為一個抽象語法樹
代碼示例
定義一個能夠解釋加減法的解釋器作為示例
先定義抽象表達式
接著定義加減法兩個非終結(jié)符表達式
再接著定義常量與變量兩個終結(jié)符表達式
然后定義上下文環(huán)境，用Map存放各個終結(jié)符對應(yīng)的具體值
最后客戶端調(diào)用
輸出結(jié)果
可能看到輸出結(jié)果的你還是一臉懵逼，到底解釋器模式做了些什么？
答：定義了一套簡單語法，每個終結(jié)符都有一個對應(yīng)的值存起來了，
然后當你輸了一串終結(jié)符，最后解釋能得出一個正確結(jié)果。
本節(jié)示例代碼：
https://github.com/coder-pig/DesignPatternsExample/tree/master/19.Interpreter%20Pattern
