接口隔离模式
在组件构建过程中，某些接口之间直接的依赖常常会带来很多问题、甚至根本无法实现。采用添加一层间接（稳定）接口，来隔离本来互相紧密关联的接口是一种常见的解决方案
Facade门面模式
1.1 动机
如果某个方案的组件的客户和组件中各个复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临着很多变化的挑战
如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系统之间的依赖相互解耦？
1.2 讲解
在这个模式中，更重要的是如何划分一个系统的边界。
例如，图书馆是一个非常复杂的系统，虽然图书按照一定规则摆放，但也只有内部人员比较清楚，作为一位初次来的访客，想要快速找到一本书，最好的办法是直接问图书管理员，而不是先了解这个图书馆的设计，因为你可能要来回在各个楼宇间奔走，借书的流程可能也比较长。
图书管理员就起到了简化图书馆子系统复杂度的作用，我们只要凡事询问图书管理员即可，而不需要关心他是如何与图书馆内部系统打交道的。
一般来说，外观模式可以在以下情况使用
- 首先，在设计初期阶段，应该要有意识的将不同的两个层分离，比如经典的三层架构，就需要考虑在数据访问层和业务逻辑层、业务逻辑层和表示层的层与层之间建立一个外观Facade，这个可以为复杂的子系统提供一个简单的接口，降低耦合。
- 其次，在开发阶段，子系统往往因为不断的重构演化而变得越来越复杂，大多数的模式使用时也会产生一些很多的小类，增加外观Facade可以提供一个简单的接口，减少他们之间的依赖。
第三，在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，但因为它包含非常重要的功能，新的需求开发必须依赖它。 - 你可以为新系统开发一个外观Facade类，来提供设计粗糙或高度复杂的遗留代码的比较清晰接口，让新系统与Facade对象交互，Facade与遗留代码交互所有复杂的工作。
1.3 模式定义
为子系统中的一组接口提供一个一致(稳定)的界面，Facade模式定义一个高层接口，这个接口使得这一子系统更加容易使用(复用)
1.4 结构
不同软件的Facade模式实现差别很大，但主要的差别大概如下
1.5 要点总结
- 从客户程序的角度看，Facade模式简化了整个组件系统的接口，对于组件内部与外部客户来说，达到了一种”解耦”的效果——内部子系统的任何变化不会影响到Facade接口的变化
- Facade设计模式更注重从架构的层次来看整个系统，而不是单个类的层次。Facade很多时候更是一种架构设计模式
- Facade设计模式并非一个集装箱，可以任意地放进任何多个对象。Facade模式中组件的内部应该是”相互耦合关系比较大的一系列组件”，而不是一个简单的功能集合。
弊端
外观模式并不适合于所有场景，当子系统足够易用时，再使用外观模式就是画蛇添足。
另外，当系统难以抽象出通用功能时，外观模式的设计可能也无所适从，因为设计的高层接口可能适用范围很窄，此时外观模式的意义就比较小