Android设计模式——外观模式（七大结构型）

1.外观模式介绍

        外观模式（Facade Pattern），是七大结构型设计模式之一。

        外观模式运用频率非常高，特别是第三方SDK很大概率会使用外观模式。通过一个外观类使得整个系统的接口只有一个统一的高层接口，降低用户的使用成本，也对用用户屏蔽很多实现细节。

2.外观模式的定义

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

3.外观模式的使用场景

        1.为一个复杂子系统提供一个简单接口。开发中子系统会越来越复杂，甚至被替换。外观模式提供一个简单统一的接口，对外隐藏子系统的具体实现，隔离变化。

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

4.UML类图

UML类图

5.角色介绍

        Facade：系统对外的统一接口，系统内部系统地工作。

        SystemA，SystemB，SystemC：子系统接口。

5.例子

Facade类，桌面

子系统，聊天app

子系统，聊天app 的Impl

子系统，游戏app

子系统，游戏app的Impl

客户端调用

例子分析

        DeskTop类包含两个子系统，也就是微信app和赛车游戏app，DeskTop将这两个系统封装起来，为用户提供一个统一的接口，用户只要通过DeskTop类就可以用微信app聊天和玩赛车游戏两个功能，用户不需要知道有ChatApp这个接口和它的实现类WeChat，也不需要赛车游戏相关的信息，通过DeskTop就可以了。要语音开黑的时候需要打开WeChat，打开语音聊天，然后打开赛车游戏app，有了封装后，就可以傻瓜式一键语音开黑了。外观模式使得操作更加简单易用。

6.Android源码中的外观模式

        1.比如Context，封装了很多重要的操作，如startActivity()，sendBroadcast()等等，而且Context只是一个定义了很多接口的抽象类，这些接口的功能实现并不是在Context及其子类中，而是通过其他子系统来完成，例如startActivity的真正实现是通过ActivityManageService，获取应用包相关信息则是通过PackageManageService。Context只是一个抽象类，它的真正实现在ContextImpl类中，ContextIpml就是外观类。

7.总结

        外观模式是一个高频率使用的设计模式，它的精髓在于封装二字。通过一个高层次结构为用户提供统一的API入口，使得用户通过一个类型就基本能够操作整个系统，从而减少了用户的使用成本，也能够提升系统的灵活性。

       优点：

        1.对客户程序隐藏子系统细节，因而减少了客户对于子系统的耦合，能够拥抱变化。

        2.外观类对子系统的接口封装，使得系统更易于使用。

       缺点

        1.外观类接口膨胀。由于子系统的接口都有外观类统一对外暴露，使得外观类的API接口较多，在一定程度上增加了用户使用成本。

        2.外观类没有遵循开闭原则，当业务出现变更时，可能需要直接修改外观类。

PS：读《Android源码设计模式解析与实战》中的外观模式之后的一些笔记与感悟