结构型模式之外观模式

目的

为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得之一子系统更加容易使用。

动机

当一个子系统中的组件过多时，对该子系统的功能调用是复杂，其他子系统对该子系统的依赖会变得混乱不清晰。
为了降低子系统间的依赖，可以对引入外观对象来为一个子系统提供一个统一的功能调用接口。
即在一个子系统中由多个SubSystem类，Facade类对SubSystem类整合，并向上层提供统一的该系统的功能调用接口。
对于用户来说，可以屏蔽子系统低层次的功能丰富接口，有利于其任务的简单化。
下图为编程环境中的编译子系统。

Compiler类是一个外观类，它提供给用户一个单一而简单的编译器子系统接口，编译器的外观类可方便大多数程序员的使用，同时对少数懂得如何使用底层功能的人，它并不隐藏这些底层功能。

适用性

• 为不需要深度定制的用户提供一个简单的缺省视图，而需要深度定制需跨过Facade层
• 子系统之间耦合度高，引入Facade为子系统解耦

参与者

• Facade：
  知道那些子系统类负责处理请求
  将客户的请求代理给适当的子系统对象
• SubSystem Classes：
  实现子系统功能
  处理Facade派发的任务
  没有Facade的任何相关信息，既没有指向Facade的指针

效果

• 屏蔽了Subsystem Classes，降低客户端使用难度。
• 实现了子系统与Client之间的松耦合关系，而Subsystem Classes之间高耦合度。松耦合关系使得子系统的组件变化并不直接影响到客户端。Facde使得系统具有模块化，层次化。便于消除类之间的复杂的循环依赖关系。
• 如果应用需要，可以不用屏蔽Subsystem Class。可以在系统的易用性和通用性之间做选择。

实现

• 降低客户端与子系统的耦合度
  两种配置模式
  1）Facade抽象：
  Facade的不同实现类，对应不同的不同的Subsystem Classes实现。客户通过抽象的Facade与Subsystem Classes通信。对客户屏蔽Subsystem Classes的区别。
  2）Facade配置：
  用不同的Subsystem Classes的对象装配Facade类，实现Facade的可选择性。
• 公共子系统类和私有子系统类
  子系统与类相似，类封装操作方法和变量，对外区分私有和公共。同样的子系统封装类，对外区分私有子系统类和公共子系统类。私有子系统类对外透明，公共子系统类为子系统对外暴露的接口。Facade便为公共子系统类。