结构模式之门面模式注解

门面模式没有具体的UML类图结构，其主要的思想是将已经存在的若干个子系统，或者若干个对象进行整合，以向外部提供统一的接口，这种方式类似于对一些API的封装，其实我们经常在软件开发中都会遇到这种模式，只是我们不会太注意而已。

比如现在有个业务功能，我们将其分为5个部分，分别由5个人进行开发，那么这5个人就会单独开发了自己的业务功能。此时我们需要将这5个人的功能进行整合，以向外提供一个统一的调用接口，当然我们不希望外部的系统知道这里面的具体内容，或者说如果直接提供这5个部分的内容，会让外部系统（可能是其他的开发人员需要开发的其他功能，而需要用到之前这5个部分的内容）熟悉起来很困难，此时就可以通过再次的封装，将这5个部分进行一个整合，从而提供一些具体的接口以向外进行接口的调用，而让外部不必关心所提供的接口的内部的实现内容或者调用内容。

尤其是在我们使用一些开源项目时，我们有时只需要其中的一部分功能，而在项目开发中，不必需要所有人都对这个开源项目进行熟悉，而只需要安排一个人对这个进行熟悉，然后再根据项目的业务需求，提供一些通用的API，以供其他人调用就可以了，那么对于其他人而言，就不会存在面对这个开源项目的代码的问题了，而只需要与安排熟悉这个开源项目的接口人进行API接口的协商，然后直接调用这个人封装的API即可。这就是典型的门面模式的特点。

如果从大的方面来说，比如系统级的封装来说，门面模式不应该算是一种械，或者说该种模式是从更加业务方面考虑的模式，比如MVC模式这种层次的模式是类似的。因为我们这里所说的是模式通常是针对代码的，针对一些对象的。但如果说从小的方面来说，我们将几个对象进行集中封装，以提供API这个角度来说，门面模式也是熟悉设计模式的范畴的。

门面模式没有特别的形式上的要求，所以其与其他的模式区别是非常大的，虽然其在实际使用中，不可避免地会引用第三方对象以进行封装，但是由于其没有特定的结构要求，所以很容易与其他模式进行区别。比如与代理模式，适配器模式等的区别，这些模式是明确要求其对象结构特征的。