[设计模式笔记] 外观模式（Facade Pattern）

外部与一个子系统的通信必须通过一个统一的外观（Facade）对象进行。

外观模式要求一个子系统的外部与其内部的通信必须通过一个统一的外观对象进行。外观模式提供一个高层次的接口，使得子系统更易于使用。

外观模式的外观类将客户端与子系统的内部复杂性分隔开，使得客户端只需要与外观对象打交道，而不需要与子系统内部的很多对象打交道。

结构：

• 外观（Facade）角色：客户端可以调用这个角色的方法。此角色知晓相关的（一个或者多个）子系统的功能和责任。在正常情况下，本角色会将所有从客户端发来的2请求委派到相应的子系统去。
• 子系统（subsystem）角色：可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集合。每一个子系统都可以被客户端直接调用，或者被门面角色调用。子系统并不是不知道门面的存在，对于子系统而言，门面仅仅是另外一个客户端而已。

GOF的书中指出：在外观模式中，通常值需要一个外观类，并且此外观类只有一个实例，换言之它是一个单例类。当然这并不意味着在整个系统里只能有一个外观类，而仅仅是说对每一个子系统只有一个外观类。或者说，如果一个系统有好几个子系统的话，每一个子系统有一个外观类，整个系统可以有数个外观类。

适用场景：

• 当客户程序与抽象类的实现部分之间存在着很大的依赖性时，引入Facade将这个子系统与客户以及其他的子系统分离，为一个复杂子系统提供一个简单接口，Facade可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而哪些需要更多的可定制性的用户可以越过Facade层。可以提高子