设计模式-门面模式
门面模式(Facade)是对象的结构模式，外部与一个子系统的通信必顺通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。 (参考)
门面模式的结构
由于门面模式的结构图过于抽象，因此把它稍稍具体点。假设子系统内有三个模块，分别是ModuleA, ModuleB, ModuleC，它们分别有一个示例方法，那么此时示例的整体结构图如下:
在这个对象图中，出现了两个角色：
- 门面(Facade)角色：
客户端可以调用这个角色的方法。此角色知晓相关的（一个或者多个）子系统的功能和责任。在正常情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去。
- 子系统(SubSystem)角色：
可以同时有一个或者多个子系统。每个子系统都不是一个单独的类，而是一个类的集合（如上面的子系统就是由ModuleA, ModuleB, ModuleC三个类组合而成）。每个子系统都可以被客户端直接调用，或者被门面角色调用。子系统并不知道门面的存在，对于子系统而言，门面仅仅是另外一个客户端而已。
门面模式的实现
使用门面模式还有一个附带的好处，就是能够有选择性地暴露方法。一个模块中定义的方法可以分成两部分，一部分是给子系统外部使用的，一部分是子系统内部模块之间相互调用时使用的。有了Facade类，那么用于子系统内部模块之间相互调用的方法就不用暴露给子系统外部了。
例如，定义如下a,b,c模块：
package Facade class Module { /** * 提供给子系统外部使用的 * */ fun a1(){ } /** * 提供给子系统内部使用的 * */ fun a2(){ } fun a3(){ } }
package Facade class ModuleB { /** * 提供给子系统外部使用的 * */ fun b1(){ } /** * 提供给子系统内部使用的 * */ fun b2(){ } fun b3(){ } }
package Facade class ModuleC { /** * 提供给子系统外部使用的 * */ fun c1(){ } /** * 提供给子系统内部使用的 * */ fun c2(){ } fun c3(){ } }
package Facade class ModuleFacade { val a = Module() val b = ModuleB() val c = ModuleC() //下面这些是a,b,c模块对子系统外部提供的方法 fun a1() { a.a1() } fun b1() { b.b1() } fun c1() { c.c1() } }
这样定义一个ModuleFacede类可以有效地屏蔽内部的细节，免得客户端去调用Module类时，发现一些不需要它知道的方法。比如a2()和a3()方法就不需要让客户端知道，否则既暴露了内部的细节，又认客户端迷惑。对客户端来说，他可能还要去思考a2(),a3()方法用来做什么呢？其它a2,a3()方法是内部模块之间交互的，原本就不是对子系统外部的，所以就不要让客户端知道。
一个系统可以有几个门面类
为子系统增加新行为
初学者往往以为通过继承一个门面类便可在子系统中加入新的行为，这是错误的。门面模式的用意是为子系统提供一个集中化和简化的沟通管道，而不能向子系统加入的新行为。
门面模式的优点
- 松散耦合
门面模式松散了客户端与了系统的耦合关系，让子系统内部的模块能更容易扩展和维护。
- 简单易用
门面模式让子系统更加易用，客户端不再需要了解子系统内部的实现，也不需要跟众多子系统内部的模块进行交互，只需要跟门面类交互就可以了。
- 更好的划分访问层次
通过合理使用Facade，可以帮助我们更好地划分访问的层次。有些方法是对系统外的，有些方法是系统内部使用的。把需要暴露外部的功能集中到门面中，这样既方便客户端使用，也很好地隐藏了内部的细节。
