设计模式——facade

facade 一般翻译成外观
故在国内也被称为外观模式。

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

Intent 的描述中，这种模式看起来有点像适配器，但是有一些区别。

facade 也有建筑立面，假象伪装的意思

facade模式是希望将子系统杂乱无章的接口和对象统一起来，提供一个易于使用的接口集，从而将两个系统，一般是client方，依赖子系统的一方，以及子系统这一方两个part进行解耦。
子系统可以独立变换，保持一个相对稳定的接口集——一些场景下，接口被认为是一种交互协议，这样client方和子系统各自可以独立去变化。

上面这种效果就是所谓的解耦——decouple 常常出现在一些大佬口中的术语。解耦不是完全脱离联系，而是达到各自独立变化的效果。
用代码来说
假设 client 的代码需要调用一个 do 的方法。
用C++ 写点伪代码

// ....
ret = subsys.do(p1, p2);  //子系统约定返回值和参数，其内部实现就可以独立变化，只要保证协议稳定即可
// ... 

如果subsys的变化，需要client方跟随它特定的操作，那么就是耦合的。
比如
subsys.do()被修改，增加了一个参数。client必须适应这种修改，因而他们耦合的。

在实践中，我们对未知没有遇见那么多，所以很难保证所有的模块间是一种绝对松耦合的关系，A模块变化导致B模块变化的场景实在是太多了，但是经过设计的代码能将这种连带的维护修改的代码尽量少。

Facade设计模式的用意是收缩接口——减少数量，统一规范，精简参数，让client操纵的对象尽可能少，进而达到松耦合的目的。

适配器的区别

适配器从第三方的lib 引用一个接口，第三方的角色类似Facade中的子系统，但是，适配器只需要一个第三方的接口，并且适配方有一个继承树。它是局部的，而Facade是全体的。
子系统全部组件，交互逻辑被封装到 Facade中。
Facade广泛地出现在各种类库代码中。以致于太过稀松常见，人们甚至都不怎么觉察到他的存在。