设计模式-外观模式

外观模式：为子系统的一组接口提供一个一致的界面，即定义一个高层接口。

通常情况，客户端要想达成某种诉求需要调用服务端的一系列服务，这样就会是客户端和服务端的依赖，耦合度过高。这个时候变引入了一个中间层来隔离客户端与服务端，通过分析客户端的诉求组装服务端的执行流程。进而将两个部分进行解耦和隔离。这个中间层有点类似SSM中的Spring MVC所做的事情。

外观模式通常使用于以下三种情况：

1. 客户端需要与多个子系统进行交互，通过增加中间外观层来隔离两者间的耦合度，符合迪米特法则。
2. 由于子系统在演化的过程中会越来越复杂，相关子系统也会增加，通过增加外观类来将这种复杂的变化与客户端隔离

3. 在构建一个层次结构明显的系统的时候，可以通过增加外观类来将每个子系统间进行隔离，可以将子系统的变化影响控制在本系统内部，也是每个子系统之间相对独立，可以独立进行发布。

   缺点：
   在不同系统之间交互的逻辑有所修改的时候，外观类要根据新增的逻辑进行升级改造，这点违反了开放-封闭原则，也会导致外观层所负责的业务过重，不容易维护。可以采用外观层进一步细化结构来解决。