设计模式-外观

一、摘要

本文主要是讲述结构型模式中一个比较常用的模式-外观模式，这个模式呢，有个最大的特点将细粒度的对象包装成粗粒度的对象，应用程序通过

访问这个外观对象，来完成细粒度对象的调用，外观模式一般是分布式应用和系统架构中的应用服务层的设计中常用的方式，并且一般结合外观模式+DTO来完成服务层的设计，提供分布式应用服务的高效服务，外观模式我们可以这样理解，我们通过外观的包装，使应用程序只能看到外观对象，而不会看到具体的细节对象，这样无疑会降低应用程序的复杂度，并且提高了程序的可维护性。本文将会从以下几个方面进行讲述：

       1、外观模式的使用场景和特点

       2、外观模式的实现方案。

       3、总结外观模式。

我们这里先给出一个外观模式的原理图：

这是未使用外观模式之前的情况，应用程序需自己了解对象的业务逻辑，下面给出使用外观模式后的情形：

通过外观对象来组织细粒度的服务的调用，外观对象提供给外部应用程序可以使用的服务，而具体的调用细粒度的过程则被外观对象给封装起来，当然这个过程就是封装变化的部分，而将变化的部分与应用程序进行隔离，无疑对程序的易用性和可维护性都是很大的提高。

二、外观模式的特点及使用场景

      外观模式的主要思想是将复杂的细粒度的对象服务包装成简单的易使用的粗粒度的功能服务，我们大家最容易理解和知道的外观模式就是，使用的API接口的封装，我们将第三方的API接口引入到我们的项目中的时候，我们需要对这些接口进行包装，将细粒度的具体调用过程进行包装成外观类的形式，通过外观类来进行统一的调用。我们平时把一些常用的公共方法也可以简易的称之为外观模式，我们将复杂的细粒度的功能，包装成一个比较通用的简易的的粗粒度的功能。我们来看看哪些场景下，我们使用外观模式很适合呢？

      1、我们在使用第三方类库或者API的时候，我们通过本地的API接口的封装，来完成对第三方API接口的粗粒度外观对象，通过这个外观对象可以很容易的完成服务的调用。我们这里举例说明吧，例如现在我有一个发送手机短信的API接口，是第三方提供给我的API接口，那么我如何包装呢？

下面给出对API封装的相关代码和说明

      2、我们在架构设计的过程中，一次的功能访问可能需要同时的调用很多个对象，那么如果我们在服务调用的时候，能够在应用程序调用中一次就能完成所有要同时调用的对象那该多好啊，外观模式无疑是最好的原则，特别是在分布式应用中，通过远程调用服务，通过外观模式降低应用程序与服务的交互次数，同时可以降低应用程序的复杂性。外观模式+DTO（数据传输对象），提供远程服务调用的性能，这些都是好的设计方式。我们来看看简单的示例吧，我想我们更能了解其中的奥妙。看图说话吧，我们这里以一次远程同步服务为例。

未使用外观模式前：

一个简单的同步服务，由于应用程序在这次服务中为了完成同步操作，必须进行3次远程连接来进行把3个对象进行同步，那么如果我们使用外观对象之后呢，我们只需要访问一次即可完成3个对象的同步。这无疑提高了系统的性能和效率。

并且通过DTO来进行传输的话，可以提供远程服务调用的访问此时和效率。

效果及实现要点
　　1．Facade模式对客户屏蔽了子系统组件，因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。
　　2．Facade模式实现了子系统与客户之间的松耦合关系，而子系统内部的功能组件往往是紧耦合的。松耦合关系使得子系统的组件变化不会影响到它的客户。
　　3．如果应用需要，它并不限制它们使用子系统类。因此你可以在系统易用性与通用性之间选择。
适用性
　　1．为一个复杂子系统提供一个简单接口。
　　2．提高子系统的独立性。
　　3．在层次化结构中，可以使用Facade模式定义系统中每一层的入口。
总结
　　Facade模式注重的是简化接口，它更多的时候是从架构的层次去看整个系统，而并非单个类的层次。

注意和其他设计模式的区别

 

代理模式
1 代理模式中的原类和代理类继承同一父类；
2 原类对象与代理类对象接口相同，功能一致；
3 起到了隐藏原类的作用。

适配器模式
1 只有适配器继承目标接口；
2 将原有类接口转换为目标代码需求的接口。

外观模式
是多个类的集成、统一适配。