外观模式

在组件构建过程中，某些接口之间直接的依赖常常会带来很多的问题、甚至根本无法实现。采用添加一层间接（稳定）接口，来隔离本来互相紧密关联的接口是种常见的解决方案。

典型的模式有：Facade,Proxy,Adapter,Mediator

考虑以下情况：

 上述A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。

如何简化外部客户程序和系统间的交互接口？如何将外部客户程序的演化和内部子系统的变化之间的依赖互相解耦？

外观模式定义

为子系统中的一组接口提供一个一致（稳定）的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用（复用）。
                                                                          --《设计模式》GoF

上述的B方案中，我们就提供了Facade这个高层接口，外部客户程序只访问这个接口，内部子系统外部是看不到的。外观模式没有一个统一化的类图描述。通常用如下图描述：

其中，

1.Facade知道哪些子系统类负责处理请求；将客户的请求代理给适当的子系统对象。

2.Subsystem classess 实现了子系统的功能；处理有Facade对象指派的任务；没有Facade的任何相关信息，即没有指向Facade的指针。

要点总结

 

• 从客户程序的角度来看，Facade模式简化了整个组件系统的接口，对于组件内部与外部客户程序来说，达到了一种“解耦”的效果--内部子系统的任何变化不会影响到Facade接口的变化。
• Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facade很多时候更是一种架构设计模式。
• Facade设计模式并非一个集装箱，可以任意地放进任何多个对象。模式中组件的内部应该是“相互耦合关系比较大的一系列组件”，而不是一个简单的功能集合。

外观模式适用性

• 要为一个复杂的子系统提供一个简单的接口时，子系统往往因为不断演化而变得越来越复杂。大多数模式使用都会产生更小的类，这使得子系统具有可重用性，也更容易对子系统进行定制，但也给那些不需要定制子系统的用户带来一些使用上的困难。Facade可以提供一个简单的默认视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过Facade层。
• 客户程序与抽象类的实现部分之间存在很大的依赖性。引入Facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
• 当需要构建一个层次结构的子系统时，使用Facade模式定义子系统中每层的入口的。如果子系统之间是相互依赖的，则可以让它们仅通过Facade进行通信。从而简化了它们之间的依赖关系。