物件導向程式設計思想 直譯器模式

一、引言

我們常常在會在字串中搜尋匹配字元或判斷乙個字串是否符合我們要的格式時，使用正規表示式，可解決問題的背後是一種什麼思想呢？即我們今天要學習的內容，直譯器模式

二、直譯器模式

定義：給定乙個語言，定義它的文法的一種表示，並定義乙個直譯器，這個直譯器使用該表示來解釋語言中的句子

1.文法：即語法規則。在直譯器模式中每乙個語法都對應乙個直譯器物件，用來處理相應的語法規則。它對於擴充套件、改變文法規則都很方便

2.可以通過抽象語法樹（abstract syntax tree，ast）的圖形方式來直觀的表示語言的構成，每一棵抽象語法樹對應乙個語言例項

下面是直譯器模式的結構圖

下面是**demo：

abstract

class
expression
else
}public
abstract
void excute(string key,double
value);
}class
note : expression
console.write(note);}}
class
scale : expression
console.write(scale);}}
//演奏內容
}//定義abstractexpression介面
inte***ce
iexpression
//定義具體的expression，這裡包括對英文單詞的翻譯和英文句號的翻譯
class
wordexpression : iexpression
public
void
interpret(stringbuilder sb)
}//對英文句號的翻譯
class
symbolexpression : iexpression
public
void
interpret(stringbuilder sb)}}
//將直譯器組合起來包裝，方便外部呼叫
優點：
1.易於實現文法。一條語法規則用乙個直譯器來解釋執行，直譯器只需要考慮這一條語法規則的實現就可以了
2.易於擴充套件新的語法。可以通過繼承等方式建立相應的直譯器物件
缺點：
1.執行效率低。直譯器模式中使用了大量的迴圈或遞迴呼叫
2.對於複雜文法難以維護。每一條規則至少需要定義乙個類，如果乙個語言包含太多的文法規則，類的過程會急劇增加，導致系統難以管理和維護
適用場景：
1.當乙個語言需要解釋執行，並可以將語言中的句子表示為乙個抽象的語法樹的時候
2.一些重複出現的問題可以用一種簡單的語言表達
3.乙個語言的文法較為簡單
4.當執行效率不是關鍵和主要關心的問題
參考：大話設計模式；
 
物件導向程式設計思想 狀態模式
一 引言 上篇部落格中學習了中介者模式，我們留下了乙個問題，當出現多個玩家需要輸贏狀態條件判斷時，可不可以不去修改中介者類，因為如果每新增乙個條件判斷，就要修改中介者類，破壞了封裝，違背開閉原則。今天我們學習的內容就是要解決這種業務場景，狀態模式 二 狀態模式 定義 當乙個物件的內在狀態改變時允許改...
物件導向程式設計思想 命令模式
一 引言 起初餐館吃飯都是客人和廚師直接溝通，菜譜是一樣的，可是客人多了的時候，有的客人可能有急事不吃了要退單，還有的客人點很多菜需要記錄類別和次序等現象，這時服務員角色的出現解決了問題。那麼面對某些無法抵禦變化的 緊耦合 的場景如何做程式設計呢？命令模式設計便出現了，使得 行為請求者 與 行為實現...
物件導向程式設計思想 外觀模式
一 引言 每逢去吃午飯路上，幾個同事都要討論一番投資理財的事情，時間久之，小白的我才勉強了解到 與 的區別，是自身直接與某只 交易，可以通過分紅或者低買高賣獲利 自身需要分析 多隻 的 如圖示一 而 是把錢交給 公司，有專業人員幫你分析 或債券等幫你理財 自身不需要直接關注 了，見圖示二 圖示一 圖...