解釋器模式

• 定義
  給定一門語言，定義它的問法的一種表示，并定義一個解釋器，該解釋器使用該表示來解釋語言中的句子。
• 自我理解
  有點類似匯編的感覺，自己定義解析規(guī)則，處理一串輸入的數(shù)據(jù)源。

• 類圖

  
  
  image.png
• AbstractExpression
  抽象解釋器
• TerminalExpression
  終結(jié)符表達式、類似于定義表達式（a+b-c） a b c 。
• NonterminalExpression
  非終結(jié)符表達式、類似表達式（ab-c\d）里面的 \ + -
• Context
  環(huán)境角色、具體到例子中采用的hashmap代替

總結(jié)

• 優(yōu)點
  解釋器是一個簡單語法分析工具，顯著優(yōu)點是擴展性。修改語法規(guī)則只要修改相應(yīng)的非終結(jié)符表達式（即 參數(shù)。非終結(jié)符為 運算符號）

• 缺點
  解釋器模式會引起類膨脹
  解釋器模式采用遞歸調(diào)用方法（邏輯調(diào)試都顯得復(fù)雜）
  效率 相對于比較低下，當一條鏈非常復(fù)雜 冗長的時候

• 場景
  重復(fù)發(fā)生問題，需要進行分析操作
  簡單語法需要解釋場景

• 注意
  避免使用該模式，維護很蛋疼。例子好了好久才看懂，雖然內(nèi)容不復(fù)雜。

享元模式

• 定義
  使用共享對象可有效地支持大量的細顆粒的對象。
• 自我理解
  自己理解的是相似的資料抽取成一個狀態(tài)類，然后需要相同狀態(tài)時都是進行引用。這個狀態(tài)是不能修改的。感覺跟作者想的不一樣！！

• 類圖

  
  
  image.png
• Summary
  該模式理解不夠透徹，感覺像是 單例模式+工廠模式。但是這樣的話，考慮到并行，或者生命周期過程造成的數(shù)值變更問題。
  //todo留坑

• 注意
  1、關(guān)于自定義類的equals的定義是需要重寫 hashcode（）和equals（）方法。

public boolean equals (Object obj){
if(obj instanceof XX){
return  //相關(guān)條件，如成員變量的值；
}
return false;

}

public int hashCode(){
return // 自定義算法。eg xx.hashCode()+yy.hashCode();
}

2、建議使用String等原始數(shù)據(jù)類型，效率方面高很多很多。

橋梁模式