外观模式

概念

外观模式提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。

适用场景

1.当需要简化并统一一个很大的接口或者一群复杂的接口时，使用外观。

2.客户程序与抽象类的实现部分之间存在着很大的依赖性。引入facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。

3.当需要构建一个层次结构的子系统时，使用facade模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，可以让他们仅通过facade进行通讯，从而简化了他们之间的依赖关系。

结构

1.尽管下图中的facade只有一个子系统，但实际上facade可以有多个子系统并提供一个统一的接口。

2.也可以为一个子系统提供一个以上的外观

外观（facade） 是模式的核心，他被客户client调用，知道各个子系统的功能。同时根据客户角色已有的需求预订了几种功能组合

子系统（subsystem classes）实现子系统的功能，并处理由Facade对象指派的任务。对子系统而言，facade和client是未知的，没有Facade的任何相关信息；即没有指向Facade的实例。

客户（client）调用facade角色获得完成相应的功能。

优缺点

优点

1.提供简化的接口的同时，依然将系统完整的功能暴露出来，以供需要的人使用。即外观模式没有“封装”子系统的类，外观只提供简化的接口。所以客户如果觉得有必要，依然可以直接使用子系统的类。

2.实现了子系统与客户之间的松耦合关系，这使得子系统的组件变化不会影响到调用它的客户类，只需要调整外观类即可

3.降低了软件系统的编译依赖性，并简化了系统在不同平台之间的移植过程。

缺点

1.不能很好的限制客户使用子系统类，如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。

2.在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”

与适配器模式的区别

适配器的意图是将接口转换成不同接口，外观的意图是简化接口

适配器模式将一个或多个类接口变成客户所期望的一个接口。虽然大多数教科书所采用的例子中适配器只适配一个类，但是你可以适配许多类来提供一个接口让客户编码。类似的，外观模式也可以针对一个拥有复杂接口的类提供简化接口。两种模式的差异，不在于它们“包装”了几个类，而是在于它们的意图。适配器模式的意图是，“改变”接口符合客户的期望；而外观模式的意图是，提供子系统的一个简化接口。