设计模式之禅——设计模式（四）

解释器模式

• 定义
  给定一门语言，定义它的问法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。
• 自我理解
  有点类似汇编的感觉，自己定义解析规则，处理一串输入的数据源。

• 类图

  
  
  

  image.png
• AbstractExpression
  抽象解释器
• TerminalExpression
  终结符表达式、类似于定义表达式（a+b-c） a b c 。
• NonterminalExpression
  非终结符表达式、类似表达式（ab-c\d）里面的 \ + -
• Context
  环境角色、具体到例子中采用的hashmap代替

总结

• 优点
  解释器是一个简单语法分析工具，显著优点是扩展性。修改语法规则只要修改相应的非终结符表达式（即 参数。非终结符为 运算符号）

• 缺点
  解释器模式会引起类膨胀
  解释器模式采用递归调用方法（逻辑调试都显得复杂）
  效率 相对于比较低下，当一条链非常复杂 冗长的时候

• 场景
  重复发生问题，需要进行分析操作
  简单语法需要解释场景

• 注意
  避免使用该模式，维护很蛋疼。例子好了好久才看懂，虽然内容不复杂。

享元模式

• 定义
  使用共享对象可有效地支持大量的细颗粒的对象。
• 自我理解
  自己理解的是相似的资料抽取成一个状态类，然后需要相同状态时都是进行引用。这个状态是不能修改的。感觉跟作者想的不一样！！

• 类图

  
  
  

  image.png
• Summary
  该模式理解不够透彻，感觉像是 单例模式+工厂模式。但是这样的话，考虑到并行，或者生命周期过程造成的数值变更问题。
  //todo留坑

• 注意
  1、关于自定义类的equals的定义是需要重写 hashcode（）和equals（）方法。

public boolean equals (Object obj){
if(obj instanceof XX){
return  //相关条件，如成员变量的值；
}
return false;

}

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

2、建议使用String等原始数据类型，效率方面高很多很多。

桥梁模式