必知必会的设计模式9

外观模式（Facade Pattern）

属结构型设计模式，「要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行，外观模式提供了一个高层次的接口，使得系统内外易于使用」

这个模式我还是第一次遇到，其实简单来理解就是对于一个子系统的访问，如果不用类似外观模式这样去设计，那最终可能子系统的很多方法就会渗透到其他模块，造成高耦合。

按照平常的实现方式，我会设计一个单例类，通过这个类来约束子系统与外部的访问，但有时候这样使用单例模式并不是非常的恰当。这个时候外观模式就非常的对口。

外观模式强调的就是提供一个访问子系统的接口，除此之外，别的方式都不行。这其中会涉及到两个部分，

• Facade 外观
  这个一般会是一个类，里面提供一些方法供外部调用，而方法的实现又是调用子系统的方法，该类并没有自己的实现逻辑。

• 子系统
  高内聚的一个子系统，依赖于 Facade 来实现与外部的沟通。

  
  外观模式示意图.png

优缺点

• 降低耦合度，保持子系统封装的完整性。
• 提高子系统内部的灵活性。
• 如果要做扩展，就会涉及到外观类的改动，显然风险就高了。

使用场景

正如前面前面项目使用所说，它比单例模式更适合于管理一个子系统，也就是说项目里涉及到与某个小型模块对接时就可以使用，当然如果模块比较庞大，可以考虑开多个外观类，进行不同的约束。

另外一点，对外观类的要求严格来说是不能有自己的实现逻辑的，只能调用子系统的某些方法。

在 Android 中的使用

这个模式是我在看 ARouter 源码实现的时候看到的，它所要求的就是我们在使用 ARouter 时必须通过 ARouter 提供的方法进行访问，而这个 ARouter 在实现上其实也用到了单例模式。

参考内容

「设计模式之禅（第 2 版）」