一、前言

外观模式在开发过程中的运用频率非常高，通过一个外观类使得整个系统的接口只有一个统一的高层接口，这样能够降低用户的使用成本，也对用户屏蔽了很多实现细节。当然，在我们的开发过程中，外观模式也是我们封装API的常用手段。

二、定义

外观模式，又叫门面模式（Facade模式），是结构型模式，提供了一个统一的接口，用来访问子系统中的一群接口，外观模式定义了一个高层接口，让子系统更容易使用。

三、适用场景

子系统越来越复杂，增加外观模式提供简单调用接口，构建多层系统结构，利用外观对象作为每层的入口，简化层间调用。

四、相关设计模式

1、外观模式和中介者模式

外观模式关注的是外界和子系统的交互，而中介者模式关注的是子系统内部之间的交互。

2、外观模式和单例模式

通常可以把外观模式的外观对象做成单例模式，结合使用。

3、外观模式和抽象工厂模式

外观类可以通过抽象工厂获取子系统的实例，子系统可以将内部对外观类进行屏蔽。

五、代码实战

例子，在一个积分商城中有很多礼物，每一个礼物需要的积分不一样，其中我们每个人持有一定的积分，先思考一下，这个商城里面有多少个子系统呢？首先需要礼物的库存校验，还有积分校验，当前自己持有的积分是否满足礼物所要求的积分数量；还有积分支付子系统以及对接物流系统，线下配送。那么对外我们可以封装一个礼物兑换的外观类，把这些逻辑封装起来。

首先创建一个积分礼物实体类， 屏幕快照 2019-04-28 下午1.58.02.png 然后再创建三个子系统，
积分和库存校验子系统： 屏幕快照 2019-04-28 下午1.58.33.png 积分支付子系统， 屏幕快照 2019-04-28 下午1.58.45.png 物流子系统， 屏幕快照 2019-04-28 下午1.58.58.png 接着创建外观实体类， 屏幕快照 2019-04-28 下午2.00.24.png 最后测试一下， 屏幕快照 2019-04-28 下午2.00.48.png 看一下UML类图， 屏幕快照 2019-04-28 下午1.30.25.png 首先外观类GiftExchangeService，对外提供一个giftExchage方法，下边有三个子系统分别是：资格校验子系统QualifyService、积分支付子系统PointsPaymentService、物流子系统ShippingService。应用层只和外观类通信，不关心子系统。这个例子使用的实体外观类，非常完美的支持了迪米特法则，如果我们再新增了一个子系统，那么我们还需要修改外观类，不符合开闭原则，如果需要扩展的话，就将外观类定义成接口或抽象类。

六、总结

1、优点

（1）简化了调用过程，无需了解深入子系统，防止带来风险；
（2）减少系统依赖、松散耦合；
（3）更好的划分访问层次；
（4）符合迪米特法则，即最少指导原则。

2、缺点

（1）增加子系统、扩展子系统行为容易引入风险；
（2）不符合开闭原则。