设计模式基础（九）——门面模式
门面模式（Facade Design Pattern），也叫外观模式，是一种结构型模式。门面模式为子系统提供一组统一的接口，定义一组高层接口让子系统更易用。
假设有一个系统 A，提供了 a、b、c、d 四个接口。系统 B 完成某个业务功能，需要调用 A 系统的 a、b、d 接口。利用门面模式，我们提供一个包裹 a、b、d 接口调用的门面接口 x，给系统 B 直接使用。
一、应用场景
在 GoF 给出的定义中提到，“门面模式让子系统更加易用”，实际上，它除了解决易用性问题之外，还能解决其他很多方面的问题。
1.1 解决易用性问题
门面模式可以用来封装系统的底层实现，隐藏系统的复杂性，提供一组更加简单易用、更高层的接口。实际上，从隐藏实现复杂性，提供更易用接口这个意图来看，门面模式有点类似于面向对象编程思想中的迪米特法则（最少知识原则）和接口隔离原则：两个有交互的系统，只暴露有限的必要的接口。
1.2 解决性能问题
利用门面模式，我们可以将多个接口调用替换为一个门面接口调用，减少网络通信成本，提高 App 客户端的响应速度。那么，从代码实现的角度来看，该如何组织门面接口和非门面接口？
如果门面接口不多，我们完全可以将它跟非门面接口放到一块，也不需要特殊标记，当作普通接口来用即可。如果门面接口很多，我们可以在已有的接口之上，再重新抽象出一层，专门放置门面接口，从类、包的命名上跟原来的接口层做区分。如果门面接口特别多，并且很多都是跨多个子系统的，我们可以将门面接口放到一个新的子系统中。
二、总结
门面模式，其实没什么特别好说的。我们在进行系统的接口设计时，要控制接口的粒度，太大会导致接口不可复用，太小会导致接口不易用。在实际的开发中，接口的可复用性和易用性需要“微妙”的权衡。针对这个问题，我的一个基本的处理原则是：尽量保持接口的可复用性，但针对特殊情况，允许提供冗余的门面接口，来提供更易用的接口。
另外，门面模式与适配器模式有些相像，但是适配器模式是做接口转换，解决的是原接口和目标接口不匹配的问题而门面模式则做接口整合，解决的是多接口调用带来的问题。
感谢赞赏~
