解释器模式
- 定义
给定一门语言，定义它的问法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。 - 自我理解
有点类似汇编的感觉，自己定义解析规则，处理一串输入的数据源。 -
类图
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等原始数据类型，效率方面高很多很多。
