设计模式 外观模式

前言

因为该模式最典型的应用是的web项目中的service层，故不记录代码了

定义

外观模式是软件工程中常用的一种软件设计模式。它为子系统中的一组接口提供一个统一的高层接口。这一接口使得子系统更加容易使用。

相信做JAVA的各位大部分是WEB开发，那么肯定都对XXXDao，XXXService非常熟悉了，这显然和外观模式有一腿。

它主要由两部分组成，

一部分是子系统（包括接口，实现类，等等），

一部分是外观接口和实现类，外观接口负责提供客户端定制的服务，

外观实现则负责组合子系统中的各个类和接口完成这些服务，外观接口则是提供给客户端使用的，

这样就解除了客户端与子系统的依赖，而让客户端只依赖于外观接口，这是一个优秀的解耦实践。

1，实际使用当中，接口并不是必须的，虽说根据依赖倒置原则，无论是处于高层的外观层，还是处于底层的子系统，都应该依赖于抽象，但是这会倒置子系统的每一个实现都要对应一个接口，从而导致系统的复杂性增加，所以这样做并不是必须的。

2，外观接口当中并不一定是子系统中某几个功能的组合，也可以是将子系统中某一个接口的某一功能单独暴露给客户端。

3，外观接口如果需要暴露给客户端很多的功能的话，可以将外观接口拆分为若干个外观接口，如此便会形成一层外观层。

上述第三点，便是为了引出前文当中的service，相信各位做过web开发的都见过我们项目中很多的service和dao（注：小型项目或许不需要service这一层），

这一层service层，有一个非常重要的作用，就是为了方便我们管理项目中与业务逻辑相关的事物，而service层，其实是给我们的事务管理器提供了一个可以方便的配置切入点的事物管理层。

除了上述这个重要的功能外，service层同时也是组合dao层暴露给action的功能，dao层的各个类只是简单的数据操作对象，

它们不具有业务逻辑，而赋予了它们业务逻辑方便action调用的功臣，正是service这一层。

各位可以想象一下，假设没有service这一层，你的action当中有很多功能需要依赖多少个dao才可以完成工作。

同时在WEB项目中，有的项目会抽象出一层service接口和一层dao接口，这是为了降低客户端（这里的客户端可以认为是action）与业务实现细节以及service外观层与数据操作实现细节的耦合，而有的项目则没有抽象层，这也并非就是不合适的。

首先添加抽象层会大大的加剧项目的类文件数量，从而使项目的复杂性增加，而且在项目刚进入开发的时候，往往接口是不稳定的，因为我们经常会需要要给某一个service添加一个方法，而为了将方法暴露给客户端（即action），我们必须将该方法添加到对应的接口当中。

所以针对这一情况，我们更好的做法是等到接口行为相对稳定时，再考虑是否要重构去添加抽象的接口，而且现在的IDE工具都在一定程度上对重构进行了支持，比如eclipse就可以直接导出一个类的接口，所以我们完全可以在需要时快速的给项目添加抽象的接口层。

由于外观模式属于一种“大”模式，所以我们平时很少会接触到，但是有很多技术的应用，其实都有着外观模式的影子。