外观模式( Facade Pattern )： 最简单的设计模式

1. 参考书籍： 《Design Patterns: Elements of Reusable Object-Oriented Software》

设计模式用前须知

• 设计模式种一句出现频率非常高的话是，“ 在不改动。。。。的情况下， 实现。。。。的扩展“ 。
• 对于设计模式的学习者来说，充分思考这句话其实非常重要， 因为这句往往只对框架/ 工具包的设计才有真正的意义。因为框架和工具包存在的意义，就是为了让其他的程序员予以利用， 进行功能的扩展，而这种功能的扩展必须以不需要改动框架和工具包中代码为前提
• 对于应用程序的编写者， 从理论上来说， 所有的应用层级代码至少都是处于可编辑范围内的， 如果不细加考量， 就盲目使用较为复杂的设计模式， 反而会得不偿失， 毕竟灵活性的获得， 也是有代价的。

外观模式 ( Facade )

• 设计意图：

  • GOF: 为在一个子系统中的接口集提供一个统一的接口。 外观模式定义了一个高层级的接口， 可以使得子系统更容易使用。
  • 关键词： 子系统中的接口集， 统一的接口

• GOF举例：

  • 把一个系统组织成多个子系统可以帮助减少系统的复杂度。 一种常见的设计目标是， 最小化子系统之间的相互依赖和通信。
  • 考虑一个给应用程序提供了访问编译器子系统的SDK， 子系统包含了多种类， 例如 Scanner, Parser， ProgramNode, BytecodeStream， ProgramNodeBuilder 等。
  • 一些特定的应用， 可能会需要直接访问这些类。
  • 而大部分的程序员， 可能仅仅需要使用SDK来编译一些代码。
    • 对于这部分程序员而言， 编译器SDK 子系统这些强大的， 却属于底层的接口仅仅使他们的任务变得更复杂了。

• 解决方案

  • 引入一个外观类或外观接口 Facade， 为子系统中的众多基础组件提供一个单一的， 简化的接口。
    
  • 为了提供一个更高层级的， 简化的接口， 添加一个 Compiler 类。 Compiler 扮演了外观面的角色， 给用户程序员提供了一个单一的， 简单的接口。 Compiler 类可以将实现了编译器功能的基础类粘合起来， 但是又没有完全隐藏这些基础类（Scanner, Parser， ProgramNode, BytecodeStream， ProgramNodeBuilder）
    • 乍一看， 外观模式几乎就是在描述封装与模块化编程的基本思想而已， 但需要注意的是， 外观模式在提供一个外观接口时， 并没有阻止用户程序员直接访问子系统的底层接口。 这是不同于简单封装的地方。
      

外观模式总结

• 外观模式结构
  

• 从外观模式的结构图也可以看出， 它是23种设计模式中最为简单的一种， 并没有详细的类关系结构。只是用一个外观类将一些子系统的基础类或基础接口粘合起来， 在不隐藏子系统基础接口的情况下， 对外提供一个统一的， 更为简单的常用接口。