今天是设计模式连载的第六篇，记录了解释器模式，享元模式，桥梁模式。

解释器模式

理解：

• 包含语法规则和解析器，按照语法规则来使用解释器解释语法并得出结果。
• 解释器包含结束解析器和语法解析器，语法解析器必须语法解析器和结束解析器。结束解析器不能再嵌套其他解析器并且返回一个具体的数值。
• 解析器递归调用并获取最终值

分析/推导：

• 本人认为这应该是一个业务需求的具体实现。

享元模式

理解：即对象共享，对象池技术。优点是节约了内存的开销；缺点是增加了系统复杂度，并且既然对象共享，在多线程环境可能会出现问题。

桥梁模式

理解：对外的外观类型和具体的执行类型分离，使得两边可以分别横向扩展，最终将外观类型和执行类型组装起来即可

分析/推导：

• 外观类型依赖具体执行类型，并且外观类型的核心方法调用具体执行类型的接口。即 公司类依赖产品类，公司的mackMoney行为调用产品的product接口和sell接口。
• 公司不再依赖具体的产品，一家公司可以在不同时期生产销售不同产品。
• 可以理解为外观类型是具体执行类型的封装，封装任何实现类均可，只要是具有相同的类型即可。外观类型用来将上层的请求实际传递到执行类型来具体执行，做到实现类和外观类解耦，两边可分别横向扩展。
  • 牵强点的理解可以是 controller调用service，service直接调用dao。
  • controller对应上层模块，service对应外观类型，dao对应实现类型。
  • service和dao可以分别扩展。