概述
根据单一职责原则，在软件中将一个系统划分为若干个子系统(Subsystem)有利于降低整个系统的复杂性，一个常见的设计目标是使客户类与子系统之间的通信和相互依赖关系达到最小，而达到该目标的途径之一就是引入一个外观(Facade)角色，它为子系统的访问提供了一个简单而单一的入口。外观模式也就是迪米特法则的体现，通过引入一个新的外观角色可以降低原有系统的复杂度，同时降低客户类与子类的耦合度
如果没有外观角色，每个客户端可能需要和多个子系统之间进行复杂的交互，系统的耦合度将很大，而增加一个外观角色之后，客户端只需要直接与外观角色交互，客户端与子系统之间原有的复杂关系由外观角色来实现，从而降低了系统的耦合度。
注：在外观模式中所指的子系统是一个广义的概念，它可以是一个类，一个功能模块，系统的一个组成部分或者一个完整的系统
定义
外观模式(Facade Pattern):外部与一个子系统的通信通过一个统一的外观角色进行，为子系统中的一组接口提供一个一致的入口，外观模式定义了一个高度接口，这个接口使得这一子系统更加容易使用。外观模式又称为门面模式，它是一种对象结构型模式
结构图
Facade（外观角色）：在客户端可以调用这个角色的方法，在外观角色中可以知道相关的（一个或者多个）子系统的功能和责任；在正常情况下，它将所有从客户端发来的请求委托到相应的子系统中，传递给相应的子系统对象处理
SubSytem（子系统角色）：在软件系统中可以有一个或者多个子系统角色，每一个子系统可以不是一个单独的类，而是一个类的集合，它实现子系统的功能，每一个子系统都可以被客户端直接调用，或者被外观角色调用，它处理由外观类传过来的请求；子系统并不知道外观的存在，对于子系统而言，外观角色仅仅是另外一个客户端而已
外观模式的主要目的在于降低系统的复杂程度，在面向对象软件系统中，类与类之间的关系越多，并不能表示系统设计得越好，反而表示系统中类之间的耦合度太大，这样的系统在维护修改时都缺乏灵活性，因为一个类的改动会导致多个类会发生变化。而外观模式的引入很大程度上降低了类之间的通信和关系。引入外观模式之后，增加新的子系统或者移除子系统都非常方便，客户端类无须进行修改（或者极少的修改），只需要在外观类中增加或移除对子系统的引用即可
从这一点来说，外观模式在一定程度上并不符合开闭原则，增加新的子系统需要对原有系统进行一定的修改，虽然这个修改工作量不大.
经典代码
class Facade{
private SubSystemA obj1 = new SubSystemA();
private SubSystemB obj2 = new SubSystemB();
private SubSystemC obj3 = new SubSystemC();
public void method(){
obj1.method();
obj2.method();
obj3.method();
}
}
例子：文件加密模块的设计
代码实现
文件读取类：子系统类
public class FileReader {
public String read(String fileNameSrc) {
System.out.println("读取文件，获取明文：");
StringBuffer sb = new StringBuffer();
try {
FileInputStream inFS = new FileInputStream(fileNameSrc);
int data;
while((data = inFS.read())!= -1) {
sb = sb.append((char)data);
}
inFS.close();
System.out.println(sb.toString());
}catch (FileNotFoundException e) {
System.out.println("文件不存在！");
}catch(IOException e) {
System.out.println("文件操作错误!");
}
return sb.toString();
}
}
数据加密类：子系统类
public class CipherMachine {
public String encrypt(String plainText) {
System.out.println("数据加密，将明文转换为密文");
String es = "";
for(int i = 0; i < plainText.length(); i++) {
String c = String.valueOf(plainText.charAt(i) % 7);
es += c;
}
System.out.println(es);
return es;
}
}
文件保存类：子系统类
public class FileWriter {
public void write(String encryptStr, String fileNameDes) {
System.out.println("保存密文，写入文件");
try {
FileOutputStream outFS = new FileOutputStream(fileNameDes);
outFS.write(encryptStr.getBytes());
outFS.close();
}catch (FileNotFoundException e) {
System.out.println("文件不存在!");
}catch (IOException e) {
System.out.println("文件操作错误!");
}
}
}
加密外观类：外观类
public class EncryptFacade {
private FileReader reader;
private CipherMachine cipher;
private FileWriter writer;
public EncryptFacade() {
reader = new FileReader();
cipher = new CipherMachine();
writer = new FileWriter();
}
//调用其他对象的业务方法
public void fileEncrypt(String fileNameSrc, String fileNameDes) {
String plainStr = reader.read(fileNameSrc);
String encryptStr = cipher.encrypt(plainStr);
writer.write(encryptStr, fileNameDes);
}
}
客户端：
public class Client {
public static void main(String args[]) {
EncryptFacade ef = new EncryptFacade();
ef.fileEncrypt("源文件路径", "目标文件路径");
}
}
抽象外观类的引入
在标准的外观模式结构图中，如果需要增加，删除或者更换与外观类交互的子系统类，必须修改外观类或客户端的源代码，这将违背开闭原则，因此可以通过引入抽象外观类来对系统进行改进，在一定程度上解决该问题。在引入抽象外观类之后，客户端可以针对抽象外观类进行编程，对于新的业务需求，不需要修改原有外观类，而对应增加一个新的具体外观类，由新的具体外观类来关联新的子系统对象，同时通过修改配置文件来达到不修改任何源代码并更换外观类的目的
例子（修改）
以上例子的加密模块中需要更换一个加密类，不再使用原有的基于求模运算的加密类CipherMachine，而改为基于移位运算的新加密类NewCipherMachine，其中NewCipherMachine类代码如下：
基于移位运算的数据加密类：子系统类
public class NewCipherMachine {
public String encrypt(String plainText) {
System.out.println("数据加密，将明文转换为密文：");
String es = "";
int key = 10; //设置秘钥，位移数为10
for(int i = 0; i < plainText.length(); i++) {
char c = plainText.charAt(i);
//小写字母移位
if(c >= 'a' && c <= 'z') {
c += key % 26;
if(c > 'z')
c -= 26;
if(c < 'a')
c += 26;
}
//大写字母移位
if(c >= 'A' && c <= 'Z') {
c += key % 26;
if(c > 'Z')
c -= 26;
if(c < 'A')
c += 26;
}
es += c;
}
System.out.println(es);
return es;
}
}
如果不增加新的外观类，只能通过修改原有外观类EncryptFacade的源代码来实现加密类的更换，将原有的对CipherMachine类型对象的引用改为对NewCipherMachine类型对象的引用，这违背了开闭原则，因此需要通过新的外观类来实现对子系统对象引用的改变
如果增加一个新的外观类NewEncryptFacade来与FileReader类，FileWriter类以及新增加的NewCipherMachine类进行交互，虽然原有系统类库无须做任何修改，但是因为客户端代码中原来针对EncryptFacade类进行的编程，现在需要改为NewEncryptFacade类，因此需要修改客户端源代码
如何在不修改客户端代码的前提下使用新的外观类呢？ 解决方法是：引入一个抽象外观类，客户端针对抽象外观类编程，而在运行时确定具体外观类之后的文件加密模块结构图如下:
代码实现
抽象外观类
abstract class AbstractEncryptFacade {
public abstract void fileEncrypt(String fileNameSrc, String fileNameDes);
}
新加密外观类：具体外观类
public class NewEncryptFacade extends AbstractEncryptFacade {
private FileReader reader;
private NewCipherMachine cipher;
private FileWriter writer;
public NewEncryptFacade() {
reader = new FileReader();
cipher = new NewCipherMachine();
writer = new FileWriter();
}
public void fileEncrypt(String fileNameSrc, String fileNameDes) {
String plainStr = reader.read(fileNameSrc);
String encryptStr = cipher.encrypt(plainStr);
writer.write(encryptStr, fileNameDes);
}
}
基于移位运算的数据加密类：子系统类
public class NewCipherMachine {
public String encrypt(String plainText) {
System.out.println("数据加密，将明文转换为密文：");
String es = "";
int key = 10; //设置秘钥，位移数为10
for(int i = 0; i < plainText.length(); i++) {
char c = plainText.charAt(i);
//小写字母移位
if(c >= 'a' && c <= 'z') {
c += key % 26;
if(c > 'z')
c -= 26;
if(c < 'a')
c += 26;
}
//大写字母移位
if(c >= 'A' && c <= 'Z') {
c += key % 26;
if(c > 'Z')
c -= 26;
if(c < 'A')
c += 26;
}
es += c;
}
System.out.println(es);
return es;
}
}
该方法用于从XML配置文件中提取具体类名，并返回一个实例对象
public class XMLUtil {
public static Object getBean() {
try {
//创建文档对象
DocumentBuilderFactory dFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = dFactory.newDocumentBuilder();
Document doc;
doc = builder.parse(new File("config.xml"));
//获取包含类名的文本节点
NodeList nl = doc.getElementsByTagName("className");
Node classNode = nl.item(0).getFirstChild();
String cName = classNode.getNodeValue();
//通过类名生成实例对象并将其返回
Class c = Class.forName(cName);
Object obj = c.newInstance();
return obj;
}catch (Exception e) {
e.printStackTrace();
return null;
}
}
}
config.xml配置文件
<?xml version="1.0"?>
<config>
<className>NewEncryptFacade</className>
</config>
客户端测试
public class Client {
public static void main(String[] args) {
AbstractEncryptFacade ef;
ef = (AbstractEncryptFacade) XMLUtil.getBean();
ef.fileEncrypt("源文件路径", "目标文件路径");
}
}
原有外观类EncryptFacade也需作为抽象外观类AbstractEncryptFacade类的子类，更换具体外观类时只需修改配置文件，无须修改源代码，符合开闭原则。
外观角色设计补充说明：
在很多情况下为了节约系统资源，系统中中需要一个外观类的实例，换言之，外观类可以是一个单例类。因此可以通过单例模式来设计外观类，从而确保系统中只有唯一一个访问子系统的入口，并降低对系统资源的消耗。
在一个系统中可以设计多个外观类，每个外观类都负责和一些特定的子系统交互，向客户端提供相应的业务功能
试图通过外观类为子系统增加新行为的做法是错误的，外观模式的用意是为子系统提供一个集中化和简化的沟通渠道，而不是向子系统加入新行为。新行为的增加应该通过修改原有子系统类或增加新的子系统类来实现，不能通过外观类来实现。
总结
外观模式是一种使用频率非常高的设计模式，它通过引入一个外观角色来简化客户端与子系统之间的交互，为复杂的子系统调用提供一个统一的入口，使得子系统与客户端的耦合度降低，且客户端调用非常方便。外挂模式并不给系统增加任何新功能，它仅仅是简化调用接口。在几乎所有的软件中都能找到外观模式的应用，例如，绝大多数B/S系统都有一个首页或者导航页面，大部分C/S系统都提供了菜单或者工具栏，而菜单和工具栏就是C/S系统的外观角色，通过它们，用户可以快速访问子系统，降低系统的复杂程度。此外，所有涉及与多个业务对象交互的场景都可以考虑使用外观模式来进行重构，例如JavaEE中的Session外观模式
主要优点
对客户端屏蔽了子系统组件，减少了客户端所需处理的对象数目并使得子系统使用起来更加容易。通过引入外观模式，客户端代码将变得很简单，与之关联的对象也很少
实现了子系统与客户端之间的松耦关系，这使得子系统的变化不会影响到调用它的客户端，只需调整外观类即可
一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象
只是提供了一个访问子系统的统一入口，并不影响客户端直接使用子系统类
主要缺点
不能很好的限制客户端之间使用子系统类，如果对客户端访问子系统类做太多的限制则减少了可变性和灵活性
如设计不当，增加新的子系统可能需要修改外观类的源代码，这违背了开闭原则
适用场合
当要为访问一系列复杂的子系统提供一个简单入口时可以使用外观模式
客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦，从而提高子系统的独立性和可移植性
在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而通过外观类建立联系，降低层之间的耦合度