【结构型】Facade模式

外观模式主要意图是为子系统提供一个统一的接口，从而使用用户对子系统的直接依赖中，解耦合出来。Facade主要是通过为子系统统一封装个入口一样，原先用户对子系统的接口、类等都是直接访问，现在要通过Facade这层封装来访问，它就好比是个中转站、一个杂货店一样。

软件工程中就提供多层设计，最常见的就是两层、三层设计结构。比如：一个模块要有数据管理层，之上还有业务逻辑层，再之上还有展示层、控制层等等。其实此处的业务逻辑层就有可理解为Facade对象。下面先看一下不使用外观模式系统设计结构参考：

从中可以看出，系统结构混乱不堪。如果子系统随便改动一下，都有可能引起上层的一系列多米诺效应。下面再看下使用Facade模式的系统设计结构图参考：

加上Facade的好处是：子系统变动并不会引起上层的修改，最多只需要调整Facade的相关接口即可(当然这要在设计好编码)。这也是我们平时写模块时，最好要有个业务逻辑层的原因。个人见过许多编程人员在收到需求后，就开始写功能。然后界面上直接使用数据，并处理一些业务相关的，有的甚至更绝，直接在界面上监听消息等。试想下，如果哪天数据变了了？需求变了了？那界面就要大改，而且更重要的，有多个模块都需要用到这份数据，且业务逻辑也都是一样的，那怎么办？那就要变成不同的界面都是原原本本地再写一遍这个逻辑（这里又与行为型的Observer模式有点关系）。为此，业务逻辑层就显的很有必要。

前面也说过，Facade其实就像一个门店一样，用户，需要什么东西，只要子系统有的，它都可以提供。同时就跟真实商店一样，有些东西它也可以不供应。比如：一些违法、禁品等。这在实际编程中就可理解为：整个子系统的众多接口、类中，Facade可以决定需要把哪些接口、对象向高层提供，而对于某些接口其实也没必要提供。比如：一些高级接口，因为多数人用不到，只有少数高手，对底层子系统十分了解的，这些人，可以直接“伸手”向子系统要。

因此，Facade模式的主要目的、思想，是为了让系统的设计更加清晰，让上层脱离对子系统的直接依赖，并且对高层“绝大多数用户”提供一个统一一致的操作接口，以方便使用。