设计模式之外观模式

外观模式（Facade）

定义

为子系统中的一组接口提供一个一致的界面。

说明

外观模式又名门面模式，其意图是定义一个高层接口，高层接口可以将一个庞大的系统分隔成一个个独立的子系统或子模块。子系统内部的接口可以经过这个高层接口被外界调用，从而使这个子系统更容易被使用。
外观模式的主要目的是实现子系统的高内聚性，以减弱系统整体对模块或者模块对模块的耦合度，从而降低系统的复杂度。

不使用外观模式：

在不使用外观模式时，可以发现当模块间的调用逐渐增多时，模块与模块之间的耦合度变得非常大，最后形成一张可怕的复杂蛛网。一个功能的实现需要依赖众多的对象，虽然我们也划分了模块，但在如此复杂的调用面前模块的边界慢慢被弱化了，最后整个系统被夯实，无法变更也没法扩展。
正是因为这种牵一发而动全身的局面使得许多系统在开发几年后再也无力维护，只能重构。解决蛛网的办法当然不止外观模式，外观模式也不可能是最好的，但外观模式在一定程度上可以缓解这种现状。

使用外观模式：

在使用外观模式时可以明显地看到子系统边界，所有的调用都要经过Facade对象，不仅统一了子系统的接口，也可以有效地保护子系统的内部组织，提高了内聚性，降低了模块间的耦合度，提高了模块的复用性，增强了系统的可维护性。

外观模式类图：

结构

外观模式中的角色
Facade 外观角色：
客户端可以调用这个角色的方法，此角色知晓之系统中的所有功能和职责。一般情况下，本角色会将所有从客户端发来的请求委派到相应子系统去，也就是说此角色没有具体的业务逻辑，只是一个委托类。
subSystem 子系统角色：
可以有一各或多个子系统，子系统内部不能只有一个单独的类，而是众多类的集合。子系统并不知道门面类的存在，对于子系统来说门面类与客户端没有什么区别。

外观模式的优势

1. 减少了系统的相互依赖

Facade模式可以消除复杂的依赖关系。它实现了系统与客户端之间的松耦合，而子系统内部的功能组件往往是紧耦合的。松耦合的关系使得子系统的组件变化不会影响到客户端。Facade模式有助于建立层次结构系统，也有助于对对象之间的依赖关系分层。

2. 提供了系统的灵活性

系统间的依赖减少了，子系统内部以Facade类为代表为外界提供服务，只要能够保证Facade类中行为不变，子系统内部怎样优化都不会对全局系统产生影响。

3. 提高了安全性

想要访问子系统内部的属性必须经过Facade类，对于不想让外界访问的行为不必再Facade类中公开，对于访问权限自然更方便控制。

外观模式的应用

• 对分层结构系统构建时，使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。
• 当一个复杂系统的子系统很多时，外观模式可以为系统设计一个简单的接口供外界访问。
• 当客户端与多个子系统之间存在很大的联系时，引入外观模式可将它们分离，从而提高子系统的独立性和可移植性。

Tomcat 源码中有两个类RequestFacade和ResponseFacade都运用了外观模式，它的目的是为了屏蔽内部的catalina容器的相关方法，使用户免受非sevlet标准方法的干扰。