23种设计模式之解释器模式
生活随笔
收集整理的這篇文章主要介紹了
23种设计模式之解释器模式
小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.
為什么80%的碼農(nóng)都做不了架構(gòu)師?>>> ??
定義:給定一種語(yǔ)言,定義他的文法的一種表示,并定義一個(gè)解釋器,該解釋器使用該表示來(lái)解釋語(yǔ)言中句子。 類型:行為類模式 類圖: 解釋器模式是一個(gè)比較少用的模式,本人之前也沒(méi)有用過(guò)這個(gè)模式。下面我們就來(lái)一起看一下解釋器模式。解釋器模式的結(jié)構(gòu)
- 抽象解釋器:聲明一個(gè)所有具體表達(dá)式都要實(shí)現(xiàn)的抽象接口(或者抽象類),接口中主要是一個(gè)interpret()方法,稱為解釋操作。具體解釋任務(wù)由它的各個(gè)實(shí)現(xiàn)類來(lái)完成,具體的解釋器分別由終結(jié)符解釋器TerminalExpression和非終結(jié)符解釋器NonterminalExpression完成。
- 終結(jié)符表達(dá)式:實(shí)現(xiàn)與文法中的元素相關(guān)聯(lián)的解釋操作,通常一個(gè)解釋器模式中只有一個(gè)終結(jié)符表達(dá)式,但有多個(gè)實(shí)例,對(duì)應(yīng)不同的終結(jié)符。終結(jié)符一半是文法中的運(yùn)算單元,比如有一個(gè)簡(jiǎn)單的公式R=R1+R2,在里面R1和R2就是終結(jié)符,對(duì)應(yīng)的解析R1和R2的解釋器就是終結(jié)符表達(dá)式。
- 非終結(jié)符表達(dá)式:文法中的每條規(guī)則對(duì)應(yīng)于一個(gè)非終結(jié)符表達(dá)式,非終結(jié)符表達(dá)式一般是文法中的運(yùn)算符或者其他關(guān)鍵字,比如公式R=R1+R2中,+就是非終結(jié)符,解析+的解釋器就是一個(gè)非終結(jié)符表達(dá)式。非終結(jié)符表達(dá)式根據(jù)邏輯的復(fù)雜程度而增加,原則上每個(gè)文法規(guī)則都對(duì)應(yīng)一個(gè)非終結(jié)符表達(dá)式。
- 環(huán)境角色:這個(gè)角色的任務(wù)一般是用來(lái)存放文法中各個(gè)終結(jié)符所對(duì)應(yīng)的具體值,比如R=R1+R2,我們給R1賦值100,給R2賦值200。這些信息需要存放到環(huán)境角色中,很多情況下我們使用Map來(lái)充當(dāng)環(huán)境角色就足夠了。
代碼實(shí)現(xiàn)
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++){//進(jìn)行語(yǔ)法判斷,遞歸調(diào)用}Expression exp = stack.pop();exp.interpreter(ctx);} } 文法遞歸的代碼部分需要根據(jù)具體的情況來(lái)實(shí)現(xiàn),因此在代碼中沒(méi)有體現(xiàn)。抽象表達(dá)式是生成語(yǔ)法集合的關(guān)鍵,每個(gè)非終結(jié)符表達(dá)式解釋一個(gè)最小的語(yǔ)法單元,然后通過(guò)遞歸的方式將這些語(yǔ)法單元組合成完整的文法,這就是解釋器模式。解釋器模式的優(yōu)缺點(diǎn)
解釋器是一個(gè)簡(jiǎn)單的語(yǔ)法分析工具,它最顯著的優(yōu)點(diǎn)就是擴(kuò)展性,修改語(yǔ)法規(guī)則只需要修改相應(yīng)的非終結(jié)符就可以了,若擴(kuò)展語(yǔ)法,只需要增加非終結(jié)符類就可以了。 但是,解釋器模式會(huì)引起類的膨脹,每個(gè)語(yǔ)法都需要產(chǎn)生一個(gè)非終結(jié)符表達(dá)式,語(yǔ)法規(guī)則比較復(fù)雜時(shí),就可能產(chǎn)生大量的類文件,為維護(hù)帶來(lái)非常多的麻煩。同時(shí),由于采用遞歸調(diào)用方法,每個(gè)非終結(jié)符表達(dá)式只關(guān)心與自己相關(guān)的表達(dá)式,每個(gè)表達(dá)式需要知道最終的結(jié)果,必須通過(guò)遞歸方式,無(wú)論是面向?qū)ο蟮恼Z(yǔ)言還是面向過(guò)程的語(yǔ)言,遞歸都是一個(gè)不推薦的方式。由于使用了大量的循環(huán)和遞歸,效率是一個(gè)不容忽視的問(wèn)題。特別是用于解釋一個(gè)解析復(fù)雜、冗長(zhǎng)的語(yǔ)法時(shí),效率是難以忍受的。解釋器模式的適用場(chǎng)景
在以下情況下可以使用解釋器模式:- 有一個(gè)簡(jiǎn)單的語(yǔ)法規(guī)則,比如一個(gè)sql語(yǔ)句,如果我們需要根據(jù)sql語(yǔ)句進(jìn)行rm轉(zhuǎn)換,就可以使用解釋器模式來(lái)對(duì)語(yǔ)句進(jìn)行解釋。
- 一些重復(fù)發(fā)生的問(wèn)題,比如加減乘除四則運(yùn)算,但是公式每次都不同,有時(shí)是a+b-c*d,有時(shí)是a*b+c-d,等等等等個(gè),公式千變?nèi)f化,但是都是由加減乘除四個(gè)非終結(jié)符來(lái)連接的,這時(shí)我們就可以使用解釋器模式。
注意事項(xiàng)
解釋器模式真的是一個(gè)比較少用的模式,因?yàn)閷?duì)它的維護(hù)實(shí)在是太麻煩了,想象一下,一坨一坨的非終結(jié)符解釋器,假如不是事先對(duì)文法的規(guī)則了如指掌,或者是文法特別簡(jiǎn)單,則很難讀懂它的邏輯。解釋器模式在實(shí)際的系統(tǒng)開發(fā)中使用的很少,因?yàn)樗麜?huì)引起效率、性能以及維護(hù)等問(wèn)題。 轉(zhuǎn)載自www.codeceo.com轉(zhuǎn)載于:https://my.oschina.net/ecp/blog/635378
總結(jié)
以上是生活随笔為你收集整理的23种设计模式之解释器模式的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: Kafka配置消息保存时间的方法
- 下一篇: System.Net.WebExcept