设计模式的艺术之道--外观模式

设计模式的艺术之道–外观模式

声明：本系列为刘伟老师博客内容总结(http://blog.csdn.net/lovelion)，博客中有完整的设计模式的相关博文，以及作者的出版书籍推荐

本系列内容思路分析借鉴了刘伟老师的博文内容，同时改用C#代码进行代码的演示和分析(Java资料过多 C#表示默哀).

本系列全部源码均在文末地址给出。

---

本系列开始讲解结构型模式，关注如何将现有类或对象组织在一起形成更加强大的结构。
不同的结构型模式从不同的角度组合类或对象，它们在尽可能满足各种面向对象设计原则的同时为类或对象的组合提供一系列巧妙的解决方案。

• 类结构型模式
  关心类的组合，由多个类组合成一个更大的系统，在类结构型模式中一般只存在继承关系和实现关系
• 对象结构型模式
  关心类与对象的组合，通过关联关系，在一个类中定义另一个类的实例对象，然后通过该对象调用相应的方法
  7种常见的结构型模式
  

---

外观模式

去茶馆喝茶，最简单的方式就是跟茶馆服务员说想要一杯什么样的茶，是铁观音、碧螺春还是西湖龙井？正因为茶馆有服务员，顾客无须直接和茶叶、茶具、开水等交互，整个泡茶过程由服务员来完成，顾客只需与服务员交互即可，整个过程非常简单省事。服务员充当了茶馆的外观。

1.1定义

• 外观模式 (Facade Pattern)：为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
  -通过引入一个新的外观角色来降低原有系统的复杂度，同时降低客户类与子系统的耦合度
• 茶馆的小二 大公司的前台 都是外观模式的案例

1.2情景实例

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

UML类图

实例关键代码

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)             {                Console.WriteLine("文件不存在！");            }            catch(IOException e)             {                Console.WriteLine("文件操作错误！");            }            return sb.ToString();        }    }    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);        }    }    class Program    {        static void Main(string[] args)        {            EncryptFacade ef = new EncryptFacade();            ef.FileEncrypt("src.txt", "des.txt");        }    }}

现有缺点(未来变化)
在标准的外观模式结构图中，如果需要增加、删除或更换与外观类交互的子系统类，必须修改外观类或客户端的源代码，这将违背开闭原则
如何改进
针对上述问题，引入抽象外观类来对系统进行改进，在一定程度上可以解决该问题。客户端可以针对抽象外观类进行编程，对于新的业务需求，不需要修改原有外观类，而对应增加一个新的具体外观类。
改进UML类图
如增加一个新的加密方法

实例关键代码

namespace FacadeSample{    class NewEncryptFacade : AbstractEncryptFacade    {        private FileReader reader;// 维持子系统的引用        private NewCipherMachine cipher;        private 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);        }    }     class NewCipherMachine    {        public string Encrypt(string plainText)         {            Console.Write("数据新方法加密，将明文转换为密文：")        }    }        class Program    {        static void Main(string[] args)        {            //EncryptFacade ef = new EncryptFacade();            //ef.FileEncrypt("src.txt", "des.txt");            AbstractEncryptFacade ef; //针对抽象建造者编程            //读取配置文件            string facadeString = ConfigurationManager.AppSettings["facade"];            //反射生成对象            ef = (AbstractEncryptFacade)Assembly.Load("AbstractFacade").CreateInstance(facadeString);            ef.FileEncrypt("src.txt", "des.txt");            Console.Read();        }    }}

1.3模式分析

动机和意图

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

一般结构

• 外观模式包含2个角色：
• Facade（外观角色）：负责关联内部多个对象的对外管理类(门面委托人 茶馆小儿)

• SubSystem（子系统角色):系统内部的多个有相关联系的子系统(烧水的 摘茶叶的 准备茶具的)

  外观模式UML类图
  

改进后的优点

• 客户端屏蔽了子系统组件，减少了客户端所需处理的对象数目，并使得子系统使用起来更加容易
• 实现了子系统与客户端之间的松耦合关系，子系统的变化不会影响到调用它的客户端，只需要调整外观类即可
• 一个子系统的修改对其他子系统没有任何影响，而且子系统的内部变化也不会影响到外观对象

现存的缺点

• 不能很好地限制客户端直接使用子系统类
• 如果设计不当，增加新的子系统可能需要修改外观类的源代码。

适用场景
(1) 要为访问一系列复杂的子系统提供一个简单入口
(2)客户端程序与多个子系统之间存在很大的依赖性。

举例:用户开机过程 开机按钮就是开机过程的外观

实例源代码
GitHub地址
百度云地址:链接: https://pan.baidu.com/s/1cprLl8 密码: it95