引言

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

结构图

角色

外观（Façade）角色

• 客户端调用这个角色的方法。该角色知道相关的一个或多个子系统的功能和责任，该角色会将从客户端发来的请求委派带相应的子系统中去。

子系统（SubSystem）角色

• 一个类的集合。每个子系统都可以被客户端直接调用或被外观角色调用。对于子系统而言，外观仅仅是另外一个客户端，子系统并不知道外观的存在。

内容

使用了外观模式之后，客户端只依赖与外观类，从而将客户端与子系统的依赖解耦了，如果子系统发生改变，此时客户端的代码并不需要去改变。

外观模式的实现核心

• 由外观类去保存各个子系统的引用，实现由一个统一的外观类去包装多个子系统类，然而客户端只需要引用这个外观类，然后由外观类来调用各个子系统中的方法，然而这样的实现方式非常类似适配器模式

外观模式与适配器模式不同的是

• 适配器模式是将一个对象包装起来以改变其接口，而外观是将一群对象 ”包装“起来以简化其接口。它们的意图是不一样的，适配器是将接口转换为不同接口，而外观模式是提供一个统一的接口来简化接口。

应用场景

设计初期，需有意识去分层（敲过的三层和七层中，就在业务逻辑层和表示层之间建立了Façade，使得耦合性大大降低）

开发阶段，子系统往往因不断重构演化变得越来越复杂，增加Façade，减少了它们之间的依赖

维护遗留大型系统，让新系统与Façade对象交互，Façade与遗留代码交互，即可分成两部分，减少维护的困难

感想

在机房合作中，外观的意义尤为显著，我们组的分工为：G:UI层 ， D:Façade层+BLL层+Factory层， Z:IDAL层+DAL层 ，G 需要什么方法，直接就调用D写在Façade中的方法，完全不需要考虑后面的任何细节，深刻体会到解耦的美丽。