JAVA设计模式----外观模式

  最近准备好好研究下Retrifot的源代码 , 因为Retrofit的主要业务用到了外观模式,正好以前没有仔细研究过这种设计模式,同时也是为了降低研究Retrofit源码的难度,所以做下关于外观设计模式的功课。为了方便看官理解,无关的代码部分尽可能的使用了伪代码。

  进入正题 , 软件开发中时常出现,需要与多个复杂子系统进行交互的情况,倘若直接与各个子系统进行交互必定会出现较高的耦合性。如果存在某一个中间对象专门负责与各个子系统进行交互,而第三方只需要与该中间对象交互即可,这便是外观模式的由来。


QQ图片20181217152344.png

  如上图,没有使用外观模式之前,各个系统之间的交互的复杂性,而使用了外观模式后,使用Facade中间对象与各个子系统进行交互,整个系统的耦合性一下就降低了。

标准外观模式:

  外观模式中所指的子系统是一个广义的概念,它可以是一个类、一个功能模块、系统的一个组成部分或者一个完整的系统。子系统类通常是一些业务类,实现了一些具体的、独立的业务功能。
  以文件加解密为例上实例代码,文件加解密可以分为三个模块, 读取文件,加解密文件,写入文件。其UML图如下:

1354688525_6684.jpg
class FileReader  
{  
       public string Read(string fileNameSrc)   
       {  
           ......  
       }  
} 
class CipherMachine  
{  
      public string Encrypt(string plainText)   
      {  
          Console.Write("数据加密,将明文转换为密文:");  
          ......  
          return es;  
}  
class FileWriter  
{  
       public void Write(string encryptStr,string fileNameDes)   
       {  
             ......          
       }  
}

重点在EncryptFacade上,用于与各个子系统进行直接交互.

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");  
            Console.Read();  
        }  
}  

抽象外观模式

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

  使用抽象外观模式更改后的UML图.


1354689057_4412.jpg

  其中,FileReader和FileWriter使用的仍然是之前的类,这里只不过是增加了一个新的加解密类NewCipherMachine,一个新的中间对象NewEncryptFacade,一个抽象类AbstractEncryptFacade.

abstract class AbstractEncryptFacade  
{  
        public abstract void FileEncrypt(string fileNameSrc, string fileNameDes);  
}
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 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("数据加密,将明文转换为密文:");  
            。。。。。。
            return es;  
        }  
} 

这里使用配置文件,通过在代码中选择加载配置文件,从而使用对应的Facade对象,以此来调用不同的加解密类。

<?xml version="1.0" encoding="utf-8" ?>  
<configuration>  
  <appSettings>  
    <add key="facade" value="FacadeSample.NewEncryptFacade"/>  
  </appSettings>  
</configuration>  
class Program  
{  
        static void Main(string[] args)  
        {  
            AbstractEncryptFacade ef; //针对抽象外观类编程  
            //读取配置文件  
            string facadeString = ConfigurationManager.AppSettings["facade"];  
            //反射生成对象  
            ef = (AbstractEncryptFacade)。。。。。。(facadeString);  
            ef.FileEncrypt("src.txt", "des.txt");  
            Console.Read();  
        }  
} 

总结:

  自我感觉,即便是抽象外观模式,做的还是不够好,
每次要增加一个新的功能或者方法时,就需要增加一个新的功能类以及一个新的中间Facade类,虽然通过配置文件可以选择调用不同的功能类,但是感觉还是不够。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,793评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,567评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,342评论 0 338
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,825评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,814评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,680评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,033评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,687评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 42,175评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,668评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,775评论 1 332
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,419评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,020评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,978评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,206评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,092评论 2 351
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,510评论 2 343

推荐阅读更多精彩内容

  • 设计模式概述 在学习面向对象七大设计原则时需要注意以下几点:a) 高内聚、低耦合和单一职能的“冲突”实际上,这两者...
    彦帧阅读 3,734评论 0 14
  • 迪米特法则(最少知识原则) 一个软件实体应当尽可能少的与其他实体发生相互作用。 外观模式核心 为子系统提供统一的入...
    GaaraZ阅读 384评论 0 0
  • 1 场景问题# 1.1 生活中的示例## 外观模式在现实生活中的示例很多,比如:组装电脑,通常会有两种方案。 一个...
    七寸知架构阅读 6,193评论 7 57
  • 1、外观模式的概念 外观模式(Facade),可以理解为,为子系统中的一组接口提供一个一致的界面,此模式定义了一个...
    钢镚koala阅读 171评论 0 1
  • 外观模式(Facade Pattern):现在系统变得越来越复杂,子系统众多,外部要与一个子系统的通信,必须通过一...
    zidea阅读 402评论 0 6