胖虎白话学习设计模式之外观设计模式（Facade）

胖虎 2014-01-06 20:56:40

2332

分类专栏：设计模式胖虎白话学习设计模式

本文链接：https://blog.csdn.net/ljphhj/article/details/17927959

版权

胖虎白话学习设计模式之外观设计模式（Facade）
记录胖虎学习设计模式过程，不许勿喷，转载请注明出处!
http://blog.csdn.net/ljphhj

1.存在问题
开发中我们经常会遇到一种情况，客户想要实现一个功能，但是这个时候，如果让客户类去完成这个功能，那么它需要涉及到很多个“子系统”模块的很多类
这样子，客户类和系统类之间的联系太紧密了，导致耦合性太高，之后如果要修改的话会显得很蛋疼，而且这样的系统会显得很复杂，不利于开发.
所以我们要引入一个中间类来简化客户类与子系统之间的交互，为复杂的子系统调用提供一个统一的接口，
降低子系统与客户类的耦合度，且客户类调用非常方便。

（PS：有知道更多的问题，希望可以给我留言哈！）
那么引入解决方法：外观设计模式

2.外观设计模式（Facade）

外观设计模式主要用于：提供一个接口，使子系统更加容易被使用

网上看一些博主写的文章，他们的例子比较形象地讲解了这个模式，由于我自己没有想到更好的，所以就借鉴过来
为尊重原创：扒上这个牛博主的地址：http://www.uml.org.cn/sjms/201301252.asp（这篇文章的内容大部分来自于这个博文，实在写得太好了！鸣谢！）

不知道大家有没有比较过自己泡茶和去茶馆喝茶的区别，如果是自己泡茶需要自行准备茶叶、茶具和开水，如图1(A)所示，而去茶馆喝茶，最简单的方式就是跟茶馆服务员说想要一杯什么样的茶，是铁观音、碧螺春还是西湖龙井？正因为茶馆有服务员，顾客无须直接和茶叶、茶具、开水等交互，整个泡茶过程由服务员来完成，顾客只需与服务员交互即可，整个过程非常简单省事，如图1(B)所示。

图1 两种喝茶方式示意图

在软件开发中，有时候为了完成一项较为复杂的功能，一个客户类需要和多个业务类交互，而这些需要交互的业务类经常会作为一个整体出现，由于涉及到的类比较多，导致使用时代码较为复杂，此时，特别需要一个类似服务员一样的角色，由它来负责和多个业务类进行交互，而客户类只需与该类交互。外观模式通过引入一个新的外观类(Facade)来实现该功能，外观类充当了软件系统中的“服务员”，它为多个业务类的调用提供了一个统一的入口，简化了类与类之间的交互。在外观模式中，那些需要交互的业务类被称为子系统(Subsystem)。如果没有外观类，那么每个客户类需要和多个子系统之间进行复杂的交互，系统的耦合度将很大，如图2(A)所示；而引入外观类之后，客户类只需要直接与外观类交互，客户类与子系统之间原有的复杂引用关系由外观类来实现，从而降低了系统的耦合度，如图2(B)所示。

图2 外观模式示意图

外观模式中，一个子系统的外部与其内部的通信通过一个统一的外观类进行，外观类将客户类与子系统的内部复杂性分隔开，使得客户类只需要与外观角色打交道，而不需要与子系统内部的很多对象打交道。

外观设计模式的结构：
外观模式没有一个一般化的类图描述，通常使用如图2(B)所示示意图来表示外观模式。图3所示的类图也可以作为描述外观模式的结构图：

图3 外观模式结构图

由图3可知，外观模式包含如下两个角色：

(1) Facade（外观角色）：在客户端可以调用它的方法，在外观角色中可以知道相关的（一个或者多个）子系统的功能和责任；在正常情况下，它将所有从客户端发来的请求委派到相应的子系统去，传递给相应的子系统对象处理。

(2) SubSystem（子系统角色）：在软件系统中可以有一个或者多个子系统角色，每一个子系统可以不是一个单独的类，而是一个类的集合，它实现子系统的功能；每一个子系统都可以被客户端直接调用，或者被外观角色调用，它处理由外观类传过来的请求；子系统并不知道外观的存在，对于子系统而言，外观角色仅仅是另外一个客户端而已。

3. 外观模式应用实例

下面通过一个应用实例来进一步学习和理解外观模式。

1. 实例说明

某软件公司欲开发一个可应用于多个软件的文件加密模块，该模块可以对文件中的数据进行加密并将加密之后的数据存储在一个新文件中，具体的流程包括三个部分，分别是读取源文件、加密、保存加密之后的文件，其中，读取文件和保存文件使用流来实现，加密操作通过求模运算实现。这三个操作相对独立，为了实现代码的独立重用，让设计更符合单一职责原则，这三个操作的业务代码封装在三个不同的类中。

现使用外观模式设计该文件加密模块。

2. 实例类图

通过分析，本实例结构图如图4所示。

图4 文件加密模块结构图

在图4中，EncryptFacade充当外观类，FileReader、CipherMachine和FileWriter充当子系统类。

3. 实例代码

(1) FileReader：文件读取类，充当子系统类。

//FileReader.cs
using System;
using System.Text;
using System.IO;


namespace FacadeSample
{
    class FileReader
    {
        public string Read(string fileNameSrc) 
        {
	   Console.Write("读取文件，获取明文：");
            FileStream fs = null;
            StringBuilder sb = new StringBuilder();
	   try
            {
                fs = new FileStream(fileNameSrc, FileMode.Open);
                int data;
    	       while((data = fs.ReadByte())!= -1) 
                {
    		sb = sb.Append((char)data);
    	       }
     	       fs.Close();
     	       Console.WriteLine(sb.ToString());
	   }
	   catch(FileNotFoundException e) 
            {
	       Console.WriteLine("文件不存在！");
	   }
	   catch(IOException e) 
            {
	       Console.WriteLine("文件操作错误！");
	   }
	   return sb.ToString();
        }
    }
}

(2) CipherMachine：数据加密类，充当子系统类。

//CipherMachine.cs
using System;
using System.Text;


namespace FacadeSample
{
    class 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;
	}
    }
}

(3) FileWriter：文件保存类，充当子系统类。

//FileWriter.cs
using System;
using System.IO;
using System.Text;


namespace FacadeSample
{
    class FileWriter
    {
        public void Write(string encryptStr,string fileNameDes) 
        {
	   Console.WriteLine("保存密文，写入文件。");
            FileStream fs = null;
	   try
            {
     	       fs = new FileStream(fileNameDes, FileMode.Create);
                byte[] str = Encoding.Default.GetBytes(encryptStr);
                fs.Write(str,0,str.Length);
                fs.Flush();
      	       fs.Close();
	   }	
	   catch(FileNotFoundException e) 
            {
		Console.WriteLine("文件不存在！");
	   }
	   catch(IOException e) 
            {
                Console.WriteLine(e.Message);
	       Console.WriteLine("文件操作错误！");
	   }		
        }
    }
}

(4) EncryptFacade：加密外观类，充当外观类。

// EncryptFacade.cs
namespace FacadeSample
{
    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);
        }
    }
}

(5) Program：客户端测试类

//Program.cs
using System;


namespace FacadeSample
{
    class Program
    {
        static void Main(string[] args)
        {
            EncryptFacade ef = new EncryptFacade();
            ef.FileEncrypt("src.txt", "des.txt");
            Console.Read();
        }
    }
}

4. 结果及分析

编译并运行程序，输出结果如下：

读取文件，获取明文：Hello world!

数据加密，将明文转换为密文：233364062325

保存密文，写入文件。

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

5. 外观模式效果与适用场景

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

5.1 模式优点

外观模式的主要优点如下：

(1) 它对客户端屏蔽了子系统组件，减少了客户端所需处理的对象数目，并使得子系统使用起来更加容易。通过引入外观模式，客户端代码将变得很简单，与之关联的对象也很少。

(2) 它实现了子系统与客户端之间的松耦合关系，这使得子系统的变化不会影响到调用它的客户端，只需要调整外观类即可。

(3) 一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象。

5.2 模式缺点

外观模式的主要缺点如下：

(1) 不能很好地限制客户端直接使用子系统类，如果对客户端访问子系统类做太多的限制则减少了可变性和灵活性。

(2) 如果设计不当，增加新的子系统可能需要修改外观类的源代码，违背了开闭原则。

5.3 模式适用场景

在以下情况下可以考虑使用外观模式：

(1) 当要为访问一系列复杂的子系统提供一个简单入口时可以使用外观模式。

(2) 客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦，从而提高子系统的独立性和可移植性。

(3) 在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而通过外观类建立联系，降低层之间的耦合度。