0.解釋器(Interpreter)模式定義 ：
給定一門語(yǔ)言，定義它的文法的一種表示，并定義一個(gè)解釋器，該解釋器使用該表示來解釋語(yǔ)言中句子。 屬于行為型模式。
解釋器模式在實(shí)際的系統(tǒng)開發(fā)中使用的非常少，因?yàn)樗鼤?huì)引起效率、性能以及維護(hù)等問題。
解釋器模式的通用類圖如圖所示。
1.解釋器模式的優(yōu)點(diǎn)
解釋器是一個(gè)簡(jiǎn)單語(yǔ)法分析工具，它最顯著的優(yōu)點(diǎn)就是擴(kuò)展性，修改語(yǔ)法規(guī)則只要修改相應(yīng)的非終結(jié)符表達(dá)式就可以了，若擴(kuò)展語(yǔ)法，則只要增加非終結(jié)符類就可以了。
2.解釋器模式的缺點(diǎn)
解釋器模式會(huì)引起類膨脹：每個(gè)語(yǔ)法都要產(chǎn)生一個(gè)非終結(jié)符表達(dá)式，語(yǔ)法規(guī)則比較復(fù)雜時(shí)，就可能產(chǎn)生大量的類文件，為維護(hù)帶來了非常多的麻煩。
解釋器模式采用遞歸調(diào)用方法：每個(gè)非終結(jié)符表達(dá)式只關(guān)心與自己有關(guān)的表達(dá)式，每個(gè)表達(dá)式需要知道最終的結(jié)果，必須一層一層地剝繭，無(wú)論是面向過程的語(yǔ)言還是面向?qū)ο蟮恼Z(yǔ)言，遞歸都是在必要條件下使用的，它導(dǎo)致調(diào)試非常復(fù)雜。想想看，如果要排查一個(gè)語(yǔ)法錯(cuò)誤，我們是不是要一個(gè)一個(gè)斷點(diǎn)的調(diào)試下去，直到最小的語(yǔ)法單元。
效率問題：解釋器模式由于使用了大量的循環(huán)和遞歸，效率是個(gè)不容忽視的問題，特別是用于解析復(fù)雜、冗長(zhǎng)的語(yǔ)法時(shí)，效率是難以忍受的。
3.解釋器模式的使用場(chǎng)景
重復(fù)發(fā)生的問題可以使用解釋器模式：例如，多個(gè)應(yīng)用服務(wù)器，每天產(chǎn)生大量的日志，需要對(duì)日志文件進(jìn)行分析處理，由于各個(gè)服務(wù)器的日志格式不同，但是數(shù)據(jù)要素是相同的，按照解釋器的說法就是終結(jié)符表達(dá)式都是相同的，但是非終結(jié)符表達(dá)式就需要制定了。在這種情況下，可以通過程序來一勞永逸地解決該問題。
一個(gè)簡(jiǎn)單語(yǔ)法需要解釋的場(chǎng)景：為什么是簡(jiǎn)單？看看非終結(jié)表達(dá)式，文法規(guī)則越多，復(fù)雜度越高，而且類間還要進(jìn)行遞歸調(diào)用（看看我們例子中的堆棧），不是一般地復(fù)雜。想想看，多個(gè)類之間的調(diào)用你需要什么樣的耐心和信心去排查問題。因此，解釋器模式一般用來解析比較標(biāo)準(zhǔn)的字符集，例如SQL語(yǔ)法分析，不過該部分逐漸被專用工具所取代。在某些特用的商業(yè)環(huán)境下也會(huì)采用解釋器模式，我們剛剛的例子就是一個(gè)商業(yè)環(huán)境，而且現(xiàn)在模型運(yùn)算的例子非常多，目前很多商業(yè)機(jī)構(gòu)已經(jīng)能夠提供出大量的數(shù)據(jù)進(jìn)行分析。
4.簡(jiǎn)單例子
|
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
|
/** * 聲明一個(gè)抽象的解釋操作 */public interface Interpreter { public void interpret(Context context); //實(shí)際中，可以有個(gè)返回的類型，定義解釋出的數(shù)據(jù)對(duì)象 } public class XmlSaxInterpreter implements Interpreter { @Override public void interpret(Context context) { System.out.println("xml sax Interpreter:" + context.getData()); } } public class XmlDomInterpreter implements Interpreter { @Override public void interpret(Context context) { System.out.println("xml dom Interpreter:" + context.getData()); } } /** * 包含解釋器之外的一些信息 */public class Context { private String data; public String getData() { return data; } public void setData(String data) { this.data = data; } } public class Test { public static void main(String[] args) { Context context = new Context(); context.setData("一段xml數(shù)據(jù)"); new XmlSaxInterpreter().interpret(context); new XmlDomInterpreter().interpret(context); } } |
5.解釋器模式的注意事項(xiàng)
盡量不要在重要的模塊中使用解釋器模式，否則維護(hù)會(huì)是一個(gè)很大的問題。在項(xiàng)目中可以使用shell、JRuby、Groovy等腳本語(yǔ)言來代替解釋器模式，彌補(bǔ)Java編譯型語(yǔ)言的不足。我們?cè)谝粋€(gè)銀行的分析型項(xiàng)目中就采用JRuby進(jìn)行運(yùn)算處理，避免使用解釋器模式的四則運(yùn)算，效率和性能各方面表現(xiàn)良好。
