外观（Facade)模式简化了复杂子系统的调用接口，并且隐藏了子系统之间的复杂关系，只在网站建设编码过程中给客户端一个简单的调用接口。

(1)客户程序调用Facade的一个简单API来执行一个任务，可能这个任务的执行会涉及很多内部子系统的交互和合作，但是客户程序完全不知道Facade内部是如何实现的。

(2)SubSystemA和SubSystemB才是任务的真正执行者。

相较于其他模式而言，Facade模式可以说是一个比较容易理解的模式，不过其中也存在着几个比较容易混淆的问题，为了进一步理解Facade模式在服务层中的应用，下面就来看看这几个问题。

如果外观模式封装了子系统的类，那么需要底层功能的客户该如何接触这些类呢？

其实，外观模式并没有“封闭”子系统的类，外观模式只是提供简化的接口，所以如果客户有需要，依然可以直接使用底层子系统的类。外观模式的另外一个特征就是：在提供简化接口的同时，依然将系统完整的功能暴露出来，以便被需要的人使用。

清楚了这一点，下面来解决在设计服务层时常常会面临的一个问题：是否需要将所有的业务类的业务方法都暴露成为业务层中的服务接口呢？

(1)服务层是外界与业务层的隔离层，所有的功能都通过服务层向外界暴露。

(2)我们不希望外界知道内部的业务类相关信息，所以每当外界需要调用比较低层的功能时，都会经由服务层来办理。这样外界与业务层就解耦了，所

以将业务类B的方法B1在服务层中以服务方法C暴露给外界，这一步的冗余是必需的。

另外，Facade外观模式会新增功能吗，或者它只是将每一个请求转由子系统执行？

外观可以添加“智能”的功能，让子系统的使用更加方便。例如，在服务层中加人缓存机制、异常处理机制等。

还有一个问题每个子系统只能有一个外观吗？

不，可以为一个子系统创建多个外观。

最后，我们将Facade模式与Adapter适配器模式进行比较，加深对Facade模式的理解。

很多网站建设编码人员认为适配器模式与外观模式的差异在于：适配器只能包装一个类，而外观可以包装许多的类。很多时候，我们所看到的适配器都是适配一个类，但是适配器模式是可以将一个或多个类 的接口编程包装成为客户所期望的一个接口的。类似地，一个外观也可以只针对一个拥有复杂接口的类提供简化的接口。两种模式的差异不在于它们“包装” 了几个类，而在于它们的意图。适配器模式的意图是，“改变”接口使其符合客户的期望；而外观模式的意图是，提供子系统的一个简化接口。在服务层的设计中，最常用的模式就是Facade模式。