動(dòng)機(jī)（Motivation）

　　在軟件構(gòu)建過程中，如果某一特定領(lǐng)域的問題比較復(fù)雜，類似的模式不斷重復(fù)出現(xiàn)，如果使用普通的編程方式來實(shí)現(xiàn)將面臨非常頻繁的變化。在這種情況下，將特定領(lǐng)域的問題表達(dá)為某種語法規(guī)則下的句子，然后構(gòu)建一個(gè)解釋器來解釋這樣的句子，從而達(dá)到解決問題的目的。

　　例說Interpreter應(yīng)用

　　假設(shè)現(xiàn)在要寫一個(gè)程序?qū)h字轉(zhuǎn)化為數(shù)字

　　假設(shè)我們能夠把它分解為每個(gè)小部分來處理，問題就容易多了

　　上下文Context，statement是未處理的字符串，data是已經(jīng)處理后的結(jié)果

　　Interpret是解釋器，是Expression的核心。

　　個(gè)，十、百、千

　　對于萬，就比較復(fù)雜，因?yàn)槿f可以是幾千幾百幾十幾萬，因此他要包含前面千百十個(gè)的處理方法

　　客戶程序

　　tree的添加順序一定是要遵從個(gè)十百千萬。億的情況和萬差不多，如果需要，則直接擴(kuò)展一個(gè)億的Expression即可，而不用去改變原來的類，這就是Interpreter模式的優(yōu)美之處。

　　結(jié)構(gòu)（Structure）

　　對應(yīng)剛才的例子，Context是表達(dá)文法要處理的上下文。AbstractExpression對應(yīng)Expression，TerminalExpression終端表達(dá)式對應(yīng)我們的一系列GeExpression、ShiExpression等。NonterminalExpression表達(dá)式是非終端表達(dá)式，在例子中并沒有寫，可以結(jié)合組合模式的樹形結(jié)構(gòu)來使用，因?yàn)榇蟮谋磉_(dá)式有時(shí)就是由小的表達(dá)式組合起來的。

　　Interpreter模式的幾個(gè)要點(diǎn)

　　Interpreter模式的應(yīng)用場合是Interpreter模式應(yīng)用中的難點(diǎn)，只有滿足“業(yè)務(wù)規(guī)則頻繁變化，且類似的模式不斷重復(fù)出現(xiàn)，并且容易抽象為語法規(guī)則的問題”才適合使用Interpreter模式。

使用Interpreter模式來表示文法規(guī)則，從而可以使用面向?qū)ο蠹记煞奖愕?ldquo;擴(kuò)展”文法。

　　Interpreter模式比較適合簡單的文法表示，對于復(fù)雜的文法表示，Interpreter模式會產(chǎn)生比較大的類層次結(jié)構(gòu)，需要求助于語法分析生成器這樣的標(biāo)準(zhǔn)工具。

　　.NET架構(gòu)中的Interpreter

　　正則表達(dá)式就是一個(gè)典型的解釋器。ASP.NET中，把ASPx文件轉(zhuǎn)化為dll時(shí)，會對html語言進(jìn)行處理，這個(gè)處理過程也包含了解釋器的模式在里面。Interpreter模式其實(shí)有Composite模式的影子，但它們解決的問題是不一樣的。

it知識庫：C#面向?qū)ο笤O(shè)計(jì)模式縱橫談：Interpreter 解釋器模式，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。