客户端针对抽象外观类进行编程，代码片段如下：
public static void main(String[] args) { AbstractFacade facade = new Facade1(); // facade = new Facade2(); facade.method(); } 模式应用个人认为外观模式某些情况下可以看成是对既有系统的再次封装，所以各种类库、工具库(比如hutool)、框架基本都有外观模式的影子。外观模式让调用方更加简洁，不用关心内部的实现，与此同时，也让越来越多的程序猿多了个调包侠的昵称(当然了这其中也包括笔者●´ω｀●行无际)。
所以，你可能在很多开源代码中看到类似XxxBootstrap、XxxContext、XxxMain等类似的Class，再追进去看一眼，你可能发现里面关联了一大堆的复杂的对象，这些对象对于外层调用者来说几乎是透明的。
例子太多，以致于不知道举啥例子(实际是偷懒的借口O(∩_∩)O哈哈~)。
模式总结外观模式并不给系统增加任何新功能，它仅仅是简化调用接口。在几乎所有的软件中都能够找到外观模式的应用。所有涉及到与多个业务对象交互的场景都可以考虑使用外观模式进行重构。
主要优点(1) 它对客户端屏蔽了子系统组件，减少了客户端所需处理的对象数目，并使得子系统使用起来更加容易。通过引入外观模式，客户端代码将变得很简单，与之关联的对象也很少。
(2) 它实现了子系统与客户端之间的松耦合关系，这使得子系统的变化不会影响到调用它的客户端，只需要调整外观类即可。
(3) 一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象。
适用场景(1) 当要为访问一系列复杂的子系统提供一个简单入口时可以使用外观模式。
(2) 客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦，从而提高子系统的独立性和可移植性。
(3) 在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而通过外观类建立联系，降低层之间的耦合度。