解读设计模式----外观模式(Facade Pattern),谈阿牛讨媳妇故事

本文主要是介绍解读设计模式----外观模式(Facade Pattern),谈阿牛讨媳妇故事,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

一、模式简介

      外观模式(Facade Pattern)可以将一系列复杂的类包装成一个简单的封闭接口。也称门面模式.

 

二、模式意图

      每一种设计模式都有它的意图,我们看看设计模式的祖师们是怎么说的。按照GOF的说法,Facade模式的意图是:为了子系统中的一组接口提供一个一致的界面,Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。

      

三、模式UML(下图转自http://www.dofactory.com/)

                           

 

 四、模式参与者

      门面(Facade)角色:客户端可以调用这个角色的方法。

          此角色知晓相关的(一个或者多个)子系统的功能和责任。

          在正常情况下,本角色会将所有从客户端发来的请求委派到相应的子系统去。

          

      子系统(SubSystem)角色:可以同时有一个或者多个子系统。

          实现子系统的功能,处理由Facade对象指派的任务。

          每一个子系统都不是一个单独的类,而是一个类的集合。

          每一个子系统都可以被客户端直接调用,或者被门面角色调用。

          子系统并不知道门面的存在,对于子系统而言,门面仅仅是另外一个客户端而已。

 

五、模式的实现

     在做实现之前我们先来分享一个故事《阿牛取媳妇》,传说啊有一个很牛B的人物--阿牛,他不但多妻,还多得很特别.为什么说特别呢?因为他的所有妻子都是亲姐妹.呵呵,这样说来好象是真还有些特别,一个人把一家里的众多女儿都取到手了.实在是强,让人不得不佩服.

 

     据说,有一个叫赵员外的商人,家里有6个女人,分别叫春香、夏香、秋香、冬香、花花和朵朵。一天一个牛B人(阿牛)出现了,在河边看见这六姐妹洗衣服。所谓英雄难过美人关,一见到其中一个便心动了,什么什么的一见钟情或许就是这样的吧。然后他发现其他的5个是一个比一个漂亮,阿牛便暗地里发誓说:“我一定要将你们几个大美人一并取回家当媳妇”。当阿牛发下誓后便暗地地打听这几个大美人的情况,了解清楚了他便觉定亲自出马去追这几个美人。然后分别将其取回家做媳妇。那阿牛是怎么追的呢?追到一个取回家,然后又追第二个取回家.........是这样的吗?见下图:

                      

代码实现:

<!--

Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/

-->  1  namespace  DesignPattern.FacadePattern
 2  {
 3       class  Program
 4      {
 5           static   void  Main( string [] args)
 6          {
 7              阿牛 an  =   new  阿牛();
 8              IList wife  =  an.GetWife();
 9               for  ( int  i  =   0 ; i  <  wife.Count; i ++ )
10              {
11                  Console.WriteLine(wife[i].GetType().ToString());
12              }
13          }
14      }
15 
16       class  春香 { }
17       class  夏香 { }
18       class  秋香 { }
19       class  冬香 { }
20       class  花花 { }
21       class  朵朵 { }
22 
23       class  阿牛
24      {
25          IList wife  =   new  ArrayList();
26 
27           public  IList GetWife()
28          {
29               // 阿牛追春香
30              wife.Add( new  春香());   // 春香同意了,放入老婆队列
31              wife.Add( new  夏香());
32              wife.Add( new  秋香());
33               // 其他类似,代码略
34 
35               return  wife;
36          }
37 
38      }
39  }

   

     这样,阿牛就可以把赵员外全部的女人都取回家了。可是,在着其中阿牛发现了很大的一个问题,那就是他在反复的做重复的事情,既追美女--美女同意-->取回家当媳妇,追美女--美女同意-->取回家当媳妇......

     在OO的程序设计中,我想大家都比较清楚,我们为什么要使用OO的设计思想,通过OO的设计给我们带来的最大好处是什么?我想“复用”应该是其中一个吧,如上阿牛讨老婆,追到一个美女厚又去追第二个,这样的重复性劳动我们是不是应该想办法来解决呢?如果应用到OO的设计思想,我们应该采取什么要的设计方式来解决呢?

     我想,现在应该就是外观(Facade)模式上场的时候了,阿牛的最终目的是把赵员外的全部女人追到手,然后取回家当媳妇。那么,引入Facade模式,我们应该怎么来处理呢?既然阿牛怎么行,六个女人都可以搞顶,那么让他直接去找赵员外也应该不成问题,让赵员外直接把6个女儿全部嫁给他。

 

     通过引入Facade模式,改进后的阿牛讨媳妇的设计如下:

                       

     实现思想就是,阿牛要取到赵员外的众多女儿,如果阿牛直接去找其中的一个,然后将其取回家,这样众多的女儿他就要去重复多次相同的动作了。阿牛很聪明,也很自信,他相信怎么多美人都可以搞定,那他一定也能够搞定赵员外这个老头子,如果他便向赵员外提亲,还要求将他的全部女儿都出嫁给他。这样赵员外就充当了一个门面(Facade)角色,众多女儿则是模式参与者中的子系统角色。

     示意性代码如下:

<!--

Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/

-->  1  namespace  DesignPattern.FacadePattern
 2  {
 3       class  FacadeTwo
 4      {
 5           public   static   void  Main( string [] arags)
 6          {
 7              Father facade  =   new  Father();
 8              facade.Married();
 9          }
10      }
11 
12       public   class  春香 
13      {
14           public   void  Married()
15          {
16              Console.WriteLine( " 春香出嫁! " );
17          }
18      }
19       public   class  夏香 
20      {
21           public   void  Married()
22          {
23              Console.WriteLine( " 夏香出嫁! " );
24          }
25      }
26       public   class  秋香 
27      {
28           public   void  Married()
29          {
30              Console.WriteLine( " 秋香出嫁! " );
31          }
32      }
33       public   class  冬香 
34      { 
35           // 此处代码与上基本相似,代码略
36      }
37       public   class  花花 { }
38       public   class  朵朵 { }
39 
40       public   class  Father
41      {
42           private   readonly  春香 cx  =   new  春香();
43           private   readonly  夏香 xx  =   new  夏香();
44           private   readonly  秋香 qx  =   new  秋香();
45           private   readonly  冬香 dx  =   new  冬香();
46           // ..其他的略同,代码省
47 
48           public   void  Married()
49          {
50              cx.Married();
51              xx.Married();
52              qx.Married();
53               // ..其他的略同,代码省
54          }
55      }
56  }

     这个阿牛真的很强哈,从赵员外手上一下取了六个老婆,佩服,佩服!!!!

 

六、协作关系

      客户程序通过发送请求给Facade的方法与子系统通讯,Facade将这些消息转发给适当的子系统对象。尽管是子系统中的有关对象在做实际的工作,但Facade模式本身也必须将它的接口转换成子系统的接口。

      使用Facade的客户程序不需要直接访问子系统对象(父母包办,想娶人家女儿,直接找她老爹商量就OK!)。

 

七、相关模式 

      Abstract Factory模式可以与Facade模式一起使用以提供一个接口,这一接口可用来以一种子系统独立的方式创建子系统对象。Abatract Factory模式也可以代替Facade模式隐藏那些与平台相关的类。

      Singleton模式常在Facade模式中出现,每一个子系统只有一个门面类,而且此门面类只有一个实例,也就是说它是一个单例(Singleton)模式。但整个系统可以有多个门面类。

      Mediator模式与Facade模式的相似之处是,它抽象了一些已有的类的功能。

 

八、参考文献

Addison-Wesley,1995,p.185. 中文版:《设计模式:可复用的面向对象软件的基础》 李英军等译.

Alan Sharroway & James r.Trott.中文版:《设计模式精解》 熊节译。

Jams W.Cooper 著. 《C#设计模式》  张志华 刘云鹏译

张逸  著《软件设计精要与模式》

 

注:转载请注明出处:http://beniao.cnblogs.com/ 或http://www.cnblogs.com/   作者 :Beniao

这篇关于解读设计模式----外观模式(Facade Pattern),谈阿牛讨媳妇故事的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/696105

相关文章

在JS中的设计模式的单例模式、策略模式、代理模式、原型模式浅讲

1. 单例模式(Singleton Pattern) 确保一个类只有一个实例,并提供一个全局访问点。 示例代码: class Singleton {constructor() {if (Singleton.instance) {return Singleton.instance;}Singleton.instance = this;this.data = [];}addData(value)

MCU7.keil中build产生的hex文件解读

1.hex文件大致解读 闲来无事,查看了MCU6.用keil新建项目的hex文件 用FlexHex打开 给我的第一印象是:经过软件的解释之后,发现这些数据排列地十分整齐 :02000F0080FE71:03000000020003F8:0C000300787FE4F6D8FD75810702000F3D:00000001FF 把解释后的数据当作十六进制来观察 1.每一行数据

Java ArrayList扩容机制 (源码解读)

结论:初始长度为10,若所需长度小于1.5倍原长度,则按照1.5倍扩容。若不够用则按照所需长度扩容。 一. 明确类内部重要变量含义         1:数组默认长度         2:这是一个共享的空数组实例,用于明确创建长度为0时的ArrayList ,比如通过 new ArrayList<>(0),ArrayList 内部的数组 elementData 会指向这个 EMPTY_EL

Spring 源码解读:自定义实现Bean定义的注册与解析

引言 在Spring框架中,Bean的注册与解析是整个依赖注入流程的核心步骤。通过Bean定义,Spring容器知道如何创建、配置和管理每个Bean实例。本篇文章将通过实现一个简化版的Bean定义注册与解析机制,帮助你理解Spring框架背后的设计逻辑。我们还将对比Spring中的BeanDefinition和BeanDefinitionRegistry,以全面掌握Bean注册和解析的核心原理。

模版方法模式template method

学习笔记,原文链接 https://refactoringguru.cn/design-patterns/template-method 超类中定义了一个算法的框架, 允许子类在不修改结构的情况下重写算法的特定步骤。 上层接口有默认实现的方法和子类需要自己实现的方法

【iOS】MVC模式

MVC模式 MVC模式MVC模式demo MVC模式 MVC模式全称为model(模型)view(视图)controller(控制器),他分为三个不同的层分别负责不同的职责。 View:该层用于存放视图,该层中我们可以对页面及控件进行布局。Model:模型一般都拥有很好的可复用性,在该层中,我们可以统一管理一些数据。Controlller:该层充当一个CPU的功能,即该应用程序

迭代器模式iterator

学习笔记,原文链接 https://refactoringguru.cn/design-patterns/iterator 不暴露集合底层表现形式 (列表、 栈和树等) 的情况下遍历集合中所有的元素

《x86汇编语言:从实模式到保护模式》视频来了

《x86汇编语言:从实模式到保护模式》视频来了 很多朋友留言,说我的专栏《x86汇编语言:从实模式到保护模式》写得很详细,还有的朋友希望我能写得更细,最好是覆盖全书的所有章节。 毕竟我不是作者,只有作者的解读才是最权威的。 当初我学习这本书的时候,只能靠自己摸索,网上搜不到什么好资源。 如果你正在学这本书或者汇编语言,那你有福气了。 本书作者李忠老师,以此书为蓝本,录制了全套视频。 试

GPT系列之:GPT-1,GPT-2,GPT-3详细解读

一、GPT1 论文:Improving Language Understanding by Generative Pre-Training 链接:https://cdn.openai.com/research-covers/languageunsupervised/language_understanding_paper.pdf 启发点:生成loss和微调loss同时作用,让下游任务来适应预训

利用命令模式构建高效的手游后端架构

在现代手游开发中,后端架构的设计对于支持高并发、快速迭代和复杂游戏逻辑至关重要。命令模式作为一种行为设计模式,可以有效地解耦请求的发起者与接收者,提升系统的可维护性和扩展性。本文将深入探讨如何利用命令模式构建一个强大且灵活的手游后端架构。 1. 命令模式的概念与优势 命令模式通过将请求封装为对象,使得请求的发起者和接收者之间的耦合度降低。这种模式的主要优势包括: 解耦请求发起者与处理者