设计模式 | 外观模式

1 | 外观模式的概述

在软件开发中，有时候为了完成一项较为复杂的功能，一个客户类需要和多个业务类交互，而这些需要交互的业务类经常会作为一个整体出现，由于涉及的类比较多，导致使用时代码比较复杂，此时特别需要一个类似服务员一样角色，由它来负责和多个业务类进行交互，而客户类只需与该类交互。

外观模式通过引入一个新的外观类（Facade）来实现该功能，外观类充当了软件系统中的"服务员"，它为多个业务类的调用提供了一个统一的入口，简化了类与类之间的交互。在外观模式中，需要交互的类被称为子系统（Subsystem）。

• =》如果没有外观类，那么每个客户类需要和多个子系统之间进行复杂的交互，系统耦合度将很大，图 a 所示。
• =》引入外观类之后，客户类只需与外观类交互，客户类与子系统之间原有的复杂引用关系由外观类来实现，降低系统的耦合度，图 b 所示。

从上如可以看出，在外观模式中，一个子系统的内部与外部的通信通过一个统一的外观类进行，外观类将客户端与子系统的内部复杂性分隔开，客户端只需与外观类角色对接，从而避开与子系统内部的很多对象模块对接，有效的降低系统的耦合度。

1.1 外观模式的定义

• 外观模式：为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
• Facade Pattern:  Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

外观模式又称为门面模式，它是一种对象结构型模式。外观模式是迪米特法则的一种具体实现，通过引入一个新的外观角色来降低原有系统的复杂度，同时降低客户类与子系统的耦合度。

2 | 外观模式的结构与实现

2.1 外观模式的结构

外观模式包含以下两个角色

• (1）Facade(外观角色)：在客户端可以调用它的方法，在外观角色中可以知道相关的(一个或者多个)子系统的功能和责任；在正常情况下，它将所有从客户端发来的请求委派到相应的子系统，传递给相应的子系统对象处理。
• (2）SubSystem(子系统角色)：在软件系统中可以有一个或者多个子系统角色，每一个子系统可以不是一个单独的类，而是一个类的集合，它实现子系统的功能；每一个子系统都可以被客户端直接调用，或者被外观角色调用，它处理由外观类传过来的请求；子系统并不知道外观的存在，对于子系统而言，外观角色仅仅是另外一个客户端而已。

2.2 外观模式的实现

外观模式的主要目的在于降低系统的复杂程度，在面向对象软件系统中，类与类之间的关系越多，不表示系统设计得越好，反而表示系统中类之间的耦合度太大，这样的系统在维护和修改时都缺乏灵活性，因为一个类的改动会导致多个类发生变化，而外观模式的引人在很大程度上降低了类与类之间的耦合关系。引人外观模式之后，增加新的子系统或者移除子系统都非常方便，客户类无须进行修改(或者极少的修改)，只需要在外观类中增加或移除对子系统的引用即可。从这一点来说，外观模式在一定程度上违背开闭原则，增加新的子系统需要对原有系统进行一定的修改，虽然这个修改工作量不大。
外观模式中所指的子系统是一个广义的概念，它可以是一个类、一个功能模块、系统的一个组成部分或者一个完整的系统。子系统类通常是一些业务类，实现了一些具体的，独立的业务功能，其典型代码如下：

class SubSystemA
{
    public void MethodA()
    {
        //业务实现代码
    }
}

class SubSystemB
{
    public void MethodB()
    {
        //业务实现代码
    }
}

class SubSystemC
{
    public void MethodC()
    {
        //业务实现代码
    }
}

引入外观类，与子系统业务类之间的交互统一由外观类来完成，外观类中通常代码如下：

class Facade
{
    private SubSystemA obj1 = new SubSystemA();
    private SubSystemB obj2 = new SubSystemB();
    private SubSystemC obj3 = new SubSystemC();

    public void Method()
    {
        obj1.MethodA();
        obj2.MethodB();
        obj3.MethodC();
        Console.WriteLine("子系统所有对象模块整体整合完毕。");
    }
}

 客户端调用，代码如下：

3 | 外观模式的应用实例

3.1 实例说明

某软件公司要开发一个可应用于多个软件的文件加密模块，该模块可以对文件中的数据进行加密并将加密之后的数据存储在一个新文件中，具体的流程包括3个部分，分别是

1. 读取源文件、
2. 加密、
3. 保存加密之后的文件、

其中，读取文件和保存文件使用流来实现，加密操作通过求模运算实现。这3个操作相对独立，为了实现代码的独立重用，让设计更符合单一职责原则，这3个操作的业务代码封装在3个不同的类中。现使用外观模式设计该文件加密模块。

3.2 实例类图

3.3 实例代码

• 外观类：EncryptFacade
• 子系统类：

1. FileReader 文件读取类
2. CipherMachine 数据加密类
3. FileWriter 文件保存类

CipherMachine 代码：

public string Encrypt(string plainText) 
{
	Console.Write("数据加密，将明文转换为密文：");
	string es = "";
    char[] chars = plainText.ToCharArray();
	foreach(char ch in chars) 
    {
        string c = (ch % 7).ToString();
		es += c;
	}
    Console.WriteLine(es);
	return es;
}

EncryptFacade 代码：

/// <summary>
/// 加密外观类
/// </summary>
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);
    }
}

 客户端调用

在本实例中，对文件 src.txt 中的数据进行加密，该文件中的内容为“Hello FacadePattern!”，加密之后将密文保存到另外一个文件 des.txt 中，程序运行后保存在该文件件中的密文为“23336406162336443255”。在加密类 CipherMachine 中，采用求模运算对明文进行加密，将明文中的每个字符除以一个整数（本例中为7，可以由用户进行设置）后取余数作为密文。

3.4 抽象外观类

在标准的外观模式结构图中，如果需要增加、删除或更换与外观类交互的子系统类，必须修改外观类或客户端的源代码，这将违背开闭原则，因此可以通过引入抽象外观类对系统进行改进，在一定程度上解决该问题。在引入抽象外观类之后，客户端可以针对抽象外观类进行编程，对于新的业务需求，不需要修改原有外观类，而对应增加一个新的具体外观类，由新的具体外观类来关联新的子系统对象，同时通过修改配置文件来达到不修改任何源代码并更换外观类的目的。

下面通过一个具体实例来学习如何使用抽象外观类。上面应用实例“文件加密模块”中需要更换一个加密类，不再使用原有的基于求模运算的加密类 CipherMachine ，而改为基于移位运算的新加密类 NewCipherMachine ；

思考 ？

1. 如果不新增外观类，只能通过修改原有外观类 EncryptFacade 的源代码来实现加密类的替换，将原有的加密对象类 CipherMachine 引用修改为新的加密类对象 NewCipherMachine 引用，这显然违背开闭原则，那有没有办法不违背开闭原则，同时又满足需求呢？
2. 如果我们新增一个外观类 NewEncryptFacade 与 FileReader 类、FileWriter 类和新增加的 NewCipherMachine 类进行交互，虽然原有系统类库无需做任何修改，但是在客户端代码中原来针对 EncryptFacade 类进行编程，现在需要改为 NewEncryptFacade 类，因此也需要修改客户端调用源代码，从这个角度看也违背开闭原则，那么如何在不修改客户端代码的前提下使用新的外观类呢？

解决方案

引入一个抽象外观类，客户端修改为针对抽象外观类编程，而在运行时在确定具体外观类。引入抽象外观类之后的文件加密模块结构图如下：

修改步骤如下

• 1）抽象外观类 AbstractEncryptFacade

abstract class AbstractEncryptFacade
{
   public abstract void FileEncrypt(string fileNameSrc, string fileNameDes);
}

•  2）新增（具体）外观类 NewEncryptFacade ，继承抽象外观类 AbstractEncryptFacade

/// <summary>
/// 新增（具体）外观类
/// </summary>
class NewEncryptFacade : AbstractEncryptFacade
{
    private readonly FileReader reader;
    private readonly NewCipherMachine cipher; //修改为新增的加密类引用
    private readonly FileWriter writer;

    public NewEncryptFacade()
    {
        reader = new FileReader();
        cipher = new NewCipherMachine();
        writer = new FileWriter();
    }

    public override void FileEncrypt(string fileNameSrc, string fileNameDes)
    {
        string plainStr = reader.Read(fileNameSrc); //文件读取，充当子系统
        string encryptStr = cipher.Encrypt(plainStr); //数据加密，充当子系统
        writer.Write(encryptStr, fileNameDes); //文件保持，充当子系统
    }
}

•  3）新增加密类 NewCipherMachine，基于移位运算

class NewCipherMachine
{
    public string Encrypt(string plainText) 
    {
		Console.Write("数据加密，将明文转换为密文：");
		string es = "";
		int key = 10;//设置密钥，移位数为10
        char[] chars = plainText.ToCharArray();
        foreach(char ch in chars) 
        {
            int temp = Convert.ToInt32(ch);
            //小写字母移位
			if (ch >= 'a' && ch <= 'z') {
				temp += key % 26;
			    if (temp > 122) temp -= 26;
                if (temp < 97) temp += 26;
			}
            //大写字母移位
			if (ch >= 'A' && ch <= 'Z') {
                temp += key % 26;
                if (temp > 90) temp -= 26;
                if (temp < 65) temp += 26;
			}
            es += ((char)temp).ToString();
		}
        Console.WriteLine(es);
		return es;
	}
}

•  4）添加配置文件 App.config

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="facade" value="FacadePattern.EncryptionModuleSample.NewEncryptFacade"/>
  </appSettings>
</configuration>

•  5）客户端调用

原有外观类 EncryptFacade 也需作为抽象外观类 AhatractFncrvptFacade 的子类，更换具体外观类时只需修改配置文件，无须修改源代码，符合开闭原则。

完整代码示例请查看=》https://gitee.com/dolayout/DesignPatternOfCSharp/tree/master/DesignPatternOfCSharp/FacadePattern

4 | 外观模式的优缺点与适用环境

外观模式是一种使用频率非常高的设计模式，它通过引入一个外观角色来简化客户端与子系统之间的交互，为复杂的子系统调用提供一个统一的入口，使子系统与客户端的耦合度降低，且客户端调用非常方便。外观模式并不给系统增加任何新功能，它仅仅是简化调用接口。在几乎所有的软件中都能够找到外观模式的应用，如绝大多数B/S系统都有一个首页或者导航页面，大部分C/S系统都提供了菜单或者工具栏，在这里，首页和导航页面就是B/S系统的外观角色，而菜单和工具栏就是C/S系统的外观角色，通过它们用户可以快速访问子系统，降低了系统的复杂程度，所有涉及与多个业务对象交互的环境都可以考虑使用外观模式进行重构。

4.1 外观模式的优点

• (1)它对客户端屏蔽了子系统组件，减少了客户端所需处理的对象数目，并使得子系统使用起来更加容易。通过引入外观模式，客户端代码将变得很简单，与之关联的对象也很少。
• (2)它实现了子系统与客户端之间的松耦合关系，这使得子系统的变化不会影响到调用它的客户端，只需要调整外观类即可。
• (3)一个子系统的修改对其他子系统没有任何影响，而且子系统的内部变化也不会影响到外观对象。

4.2 外观模式的缺点

• (1)外观模式不能很好地限制客户端直接使用子系统类，如果对客户端访问子系统类做太多的限制则减少了可变性和灵活性。
• (2)如果设计不当，增加新的子系统可能需要修改外观类的源代码，违背了开闭原则。

4.3 外观模式的适用环境

• (1)当要为访问一系列复杂的子系统提供一个简单统一的入口时可以使用外观模式。
• (2)客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦，从而提高子系统的独立性和可移植性。
• (3)在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而是通过外观类建立联系，降低层之间的耦合度。