模式系列谈之Facade模式

Facade与Adapter模式应用 前言 作为设计模式第一篇随笔,首先以个人粗浅了解谈一谈何为设计模式。   简单来说,对于某一类新问题,可以使用前人为旧问题设计过的解决方案。将前人设计的模式应用到新问题上,不仅避免了许多可能碰壁的尝试,同时也是站在了巨人的肩膀之上。设计模式广泛应用于建筑学、工程学等学科;对于软件工程,设计模式也不例外。 软件中最困难的部分当属需求的变化。"需求发生了变化——它和死亡、纳税都是不可避免的三件... 阅读详情

看到“门面”这个词,大家一定都觉得很熟悉。不错,这个词正是借用了我们日常生活中的“门面”的概念。日常生活中的“门面”,正是我们买东西的地方。因此可以这么说,“门面”就是这么一个地方,它们跟各种商品的生产商打交道,收集商品后,再卖给我们。换句话说,如果没有“门面”,我们将不得不直接跟各种各样的生产商买商品;而有了“门面”,我们要买东西,直接跟“门面”打交道就可以了。

Facade模式正是这样一个“门面”:我们本来需要与后台的多个类或者接口打交道,而Facade模式是客户端和后台之间插入一个中间层——门面,这个门面跟后台的多个类或接口打交道,而客户端只需要跟门面打交道即可。

使用Facade模式可以说是后台设计和编码人员的一个必备素质。我不止碰到过一个这样的后台开发人员,他们认为只要把后台功能完成了就万事大吉,而没有站在后台使用者的角度来看一看自己写出来的代码。其实,我们写出来的后台代码是要给别人使用的,所以我们提供给使用者的接口要越简单越好,这不单是对使用者好,同时对开发者也是好处多多的,至少你的接口简单了,你和使用者的交流就容易了。

而Facade模式中的Facade类正是这样一个用户接口,它和后台中的多个类产生依赖关系,而后台的客户类则只跟Facade类产生依赖关系。为什么要这么做?其中的原因十分简单:后台的开发者熟悉他自己开发的各个类,也就容易解决和多个类的依赖关系,而后台的使用者则不太熟悉后台的各个类,不容易处理和它们之间的依赖;因此,后台的开发者自己在Facade类中解决了与后台多个类之间的依赖,后台的使用者只需要处理和Facade类的依赖即可。

好了,闲话少说。我们下面就以几个具体的例子来看一看Facade模式是怎么使用的。实际编程中,能使用到Facade模式的情况有很多,以下就分两种情况来具体说一说Facade模式的使用。可能还会有其他的情况,大家在实践中也可以加以补充。

第一种情况,客户类要使用的功能分布在多个类中,这些类可能相互之间没有什么关系;客户在使用后台的时候,必须先初始化要使用到的功能所在的类,然后才能使用。这时候,适合将这些功能集中在一个Facade类里,还可以替用户做一些初始化的工作,以减轻用户的负担。
例如,以商店为例。假如商店里出售三种商品:衣服、电脑和手机。这三种商品都是由各自的生产厂商卖出的,如下:
public class CoatFactory
{
public Coat saleCoat()
{
……
return coat;
}
……
}

然后是电脑的厂家类:

public class ComputerFactory
{
public Computer saleComputer()
{
……
return computer;
}
……
}

最后是手机商类:

public class MobileFactory
{
public Mobile saleMobile()
{
……
return mobile;
}
……
}


如果没有商店,我们就不得不分别跟各自的生产商打交道,如下:

//买衣服
CoatFactory coatFactory = new CoatFactory();
coatFactory.saleCoat();
//买电脑
ComputerFactory computerFactory = new ComputerFactory();
computerFactory.saleComputer();
//买手机
MobileFactory mobileFactory = new MobileFactory();
mobileFactory.saleMobile();


对我们顾客来说,和这么多的厂家类打交道,这显然是够麻烦的。


这样,我们就需要创建一个商店类了,让商店类和这些厂家打交道,我们只和商店类打交道即可,如下:

public class Store
{
public Coat saleCoat()
{
CoatFactory coatFactory = new CoatFactory();
return coatFactory.saleCoat();
}
public Computer saleComputer()
{
ComputerFactory computerFactory = new ComputerFactory();
return computerFactory.saleComputer();
}
public Mobile saleMobile()
{
MobileFactory mobileFactory = new MobileFactory();
return mobileFactory.saleMobile();
}
}


好了,现在我们要买东西,不用去跟那么多的厂家类打交道了。

Store store =new Store();
//买衣服
store.saleCoat();
//买电脑
store.saleComputer();
//买手机
store.saleMobile();


呵呵,这样对我们客户类来说,是不是简单多了。

第二种情况客户要完成的某个功能,可能需要调用后台的多个类才能实现,这时候特别要使用Facade模式。不然,会给客户的调用带来很大的麻烦。请看下面的例子。

我经常看到后台编码人员,强迫它们的使用者写出如下的代码:

……
String xmlString = null;
int result = 0;
try
{
xmlString = gdSizeChart.buildDataXML(incBean);


String path = "D:/Eclipse3.0/workspace/PLMSuite/AppWeb/PM/productSpecification/gridfile.xml";
File f = new File(path);
PrintWriter out = new PrintWriter(new FileWriter(f));
out.print(xmlString);
out.close();
System.out.println("/r/n/r/n sumaryAction" + xmlString + "/r/n/r/n");
request.setAttribute("xmlString", xmlString);
}
catch(Exception ex)
{
ex.printStackTrace();
}


这段代码前面即省略号省略掉的一部分是客户类调用后台的一部分代码,是一个相对独立的功能。后面这一部分也是一个相对独立的功能,而后台代码设计人员却把这个功能留给客户类自己来实现。

我就很怀疑,让客户类做这么多事情,到底要你的后台做什么?你还不如直接把所有的事情都给客户类做了得了。因为,你后台做了一半,剩下的一部分给客户类做,客户类根本就不明白怎么回事,或者说他不清楚你的思路,这样做下去更加困难。可能这点逻辑对你来说,很简单。但使用者不明白你的思路啊,他不知道来龙去脉,怎么往下写?

如果在这里有一个Facade类,让它来做不该由客户类来做的事,是不是简单多了呢?如下是一个Facade类:

public class Facade
{
public static void doAll(PE_MeasTableExdBean incBean, HttpServletRequest request)
{
……
request.setAttribute(“xmlString”,Facade.getFromOut(incBean));
}
private static String getFromOut(PE_MeasTableExdBean incBean)
{
try
{
xmlString = gdSizeChart.buildDataXML(incBean);


String path = "D:/Eclipse3.0/workspace/PLMSuite/AppWeb/PM/productSpecification/gridfile.xml";
File f = new File(path);
PrintWriter out = new PrintWriter(new FileWriter(f));
out.print(xmlString);
out.close();
System.out.println("/r/n/r/n sumaryAction" + xmlString + "/r/n/r/n");
return xmlString;
}
catch(Exception ex)
{
ex.printStackTrace();
return null;
}
}
}

那么客户类的调用就是下面的样子:

Facade.doAll(incBean,request);


这样,客户是不是轻松多了?值得注意的是,Facade类中的getFromOut方法其实不应该在Facade类中,本文为了简单起见而放在了这个类中,对Facade类来说是不符合单一职责原则的。

最后总结一下第二种情况的模式。后台为实现某一个功能有如下类:

public class ClassA
{
public void doA()
{
……
}
……
}
public class ClassB
{
public void doB()
{
……
}
……
}
public class ClassC
{
public void doC()
{
……
}
……
}

如果客户类需要这样调用:

……
ClassA a = new ClassA();
a.doA();
ClassB b = new ClassB();
b.doB();
ClassC c = new ClassC();
c.doC();
……


那么就适合做一个Facade类,来替客户类来完成上述的功能,如下:

public class Facade
{
public void doAll()
{
ClassA a = new ClassA();
a.doA();
ClassB b = new ClassB();
b.doB();
ClassC c = new ClassC();
c.doC();
}
}


则客户类的调用如下:

……
Facade Facade = new Facade();
Facade.doAll();
……

紫光同创PDS软件操作指南:如何为FPGA新增自定义Flash型号 本文详细介绍了在紫光同创PDS软件中为FPGA新增自定义Flash型号的完整操作指南。针对官方支持列表之外的SPI Flash芯片,文章从理解FPGA配置逻辑入手,逐步讲解如何通过扫描Flash ID、在Flash Operator中精准填写参数、转换.sbit文件,最终完成固化的全过程,并分享了高级技巧与常见问题排查方法,帮助工程师摆脱对预设型号的依赖,实现灵活选型。 阅读详情

相关推荐

Outlook日历同步全攻略:Win10+安卓+iOS三端无缝衔接(附常见问题解决)

本文提供了一份详尽的Outlook日历同步指南,帮助用户在Windows 10、安卓和iOS三端实现无缝衔接。文章深入解析了Exchange ActiveSync等核心同步原理,并给出了从账户创建到各设备(特别是华为手机)的具体配置步骤、进阶管理技巧以及针对同步失败、事件重复等常见问题的实战解决方案,旨在彻底解决跨平台日程管理的痛点。

l3m4n的博客 552

design pattern : Facade

       使用Facade模式可以说是后台设计和编码人员的一个必备素质。我不止碰到过一个这样的后台开发人员,他们认为只要把后台功能完成了就万事大吉,而没有站在后台使用者的角度来看一看自己写出来的代码。其实,我们写出来的后台代码是要给别人使用的,所以我们提供给使用者的接口要越简单越好,这不单是对使用者好,同时对开发者也是好处多多的,至少你的接口简单了,你和使用者的交流就容易了。而Facade

dean的专栏 877

S/4中的16种特殊库存类型

S/4中的16种特殊库存类型

yanzibing99的博客 1万+

设计模式简单代码之Facade模式(编译系统篇)

/**********************************************************************************************************/* 作者:一雨田(http://blog.youkuaiyun.com/dylgsy/)。本文可随便转贴,但请保留此信息 * Facade 模式:* 门面模式,为外界提供一个统一的、简单的

一雨田的专栏 2504

Win11+VSCode+TeXLive:学术党必备的LaTeX环境配置避坑指南(2024最新版)

本文详细介绍了如何在Windows 11系统下,通过VSCode编辑器与TeXLive发行版配置高效的LaTeX学术写作环境。针对国内用户常见的镜像下载慢、插件配置复杂等问题,提供了优化方案和避坑指南,帮助科研人员和学生快速搭建流畅的学术写作工作流。

plum99的博客 619

从接线到组态:手把手教你搞定PROFIBUS-DP与PA的混合网络搭建(基于西门子TIA Portal)

本文详细介绍了PROFIBUS-DP与PA混合网络的搭建方法,基于西门子TIA Portal平台,从硬件选型、网络架构设计到组态配置和现场调试,提供了一套完整的实战指南。重点解析了DP/PA耦合器的使用、地址映射策略及网络诊断技巧,帮助工程师高效构建高可靠性的工业自动化网络。

weixin_32103009的博客 302

代码的“门面”——模式系列谈之Façade模式

                                                                    代码的“门面”                                                          ——模式系列谈之Façade模式  看到“门面”这个词,大家一定都觉得很熟悉。不错,这个词正是借用了我们日常生活中的“

软件的信雅达 4326

Hermes Agent 彩蛋大盘点:藏在终端里的浪漫

本文主要介绍了Hermes Agent 彩蛋大盘点:藏在终端里的浪漫,希望能对使用Hermes Agent的同学们有所帮助。 文章目录 1. 前言 2. Spinner 动画 3. Kawaii 表情 4. 思考动词 THINKING_VERBS 5. 皮肤主题 6. 启动 Banner 7. 工具 Emoji 8. 内置人格 9. SOUL.md —— Agent 的灵魂 10. BOOT.md —— 启动自动执行 11. 随机 Tips 12. 统计总览

weixin_43178406的博客 7万+

外观模式1

3.1  场景问题 3.1.1  生活中的示例 外观模式在现实生活中的示例很多,比如:组装电脑,通常会有两种方案。 一个方案是去电子市场把自己需要的配件都买回来,然后自己组装,绝对DIY(Do It Yourself)。这个方案好是好,但是需要对各种配件都要比较熟悉,这样才能选择最合适的配件,而且还要考虑配件之间的兼容性。如图3.1所示:   图3.1  客户完全自己组装电脑 另外一...

jasshine的专栏 203

【嘉立创EDA】从AD21导入pcb边界到嘉立创EDA专业版

有许多前期工程由AD进行完成,在后续update的过程中,由于开模等原因限制,部分pcb外型需要继续沿用,本文将此过程记录,以供有需要的读者参考。

l64481000的博客 4519

AIGC游戏本地化:用AI实现多语言自动翻译

游戏本地化是游戏全球化战略的关键环节,传统人工翻译方式成本高、周期长。本文旨在探讨如何利用AIGC技术实现高效、准确、低成本的游戏多语言自动翻译解决方案。我们将覆盖从文本翻译到语音合成的完整本地化流程,重点关注AI技术在游戏特定语境下的应用优化。文章首先介绍游戏本地化的核心挑战和AI解决方案,然后深入讲解关键技术原理,接着通过实战项目演示具体实现,最后讨论应用场景和未来趋势。AIGC:人工智能生成内容,指利用AI技术自动生成文本、图像、音频等内容本地化(Localization)

AI 领航者的博客 1338

设计模式初探(二)「Facade模式」

在以前不懂设计模式的岁月中,我总是对着各种语言框架中的那个Facades模块不知所措。当对设计模式有了一定的了解以后,提升的不仅仅是自己写代码时的所思所想,对于框架的理解程度,和学习框架的速度也会上一个台阶。Facade模式简介Facade模式主要是为了解决开发中各个子系统之间的紧密耦合的问题。 这是一个来自《设计模式的艺术》中的一幅图,很生动的展示了什么时候应该使用Facade模式。一图胜过千言

C++ 引发的血案 298

YTM32B1M SDK解析31:软件I2C驱动详解

YTM32B1M微控制器软件I2C驱动解析 本文详细介绍了YTM32B1M微控制器中通过GPIO引脚模拟I2C总线的软件实现方案。核心内容包括: 驱动架构:采用swi2c_config_t配置结构体和swi2c_state_t状态结构体管理I2C参数 功能接口:提供初始化、数据传输(主/从模式)、底层控制等API 应用示例:包含基本配置、EEPROM读写、传感器数据采集、总线扫描等典型应用场景 优化建议:给出引脚选择、时序配置、错误处理等方面的最佳实践 该驱动在硬件I2C资源不足时提供可靠替代方案,支持标准

VehSwHwDeveloper的博客 158

代码的“门面”——模式系列谈之Facade模式

看到“门面”这个词,大家一定都觉得很熟悉。不错,这个词正是借用了我们日常生活中的“门面”的概念。日常生活中的“门面”,正是我们买东西的地方。因此可以这么说,“门面”就是这么一个地方,它们跟各种商品的生产商打交道,收集商品后,再卖给我们。换句话说,如果没有“门面”,我们将不得不直接跟各种各样的生产商买商品;而有了“门面”,我们要买东西,直接跟“门面”打交道就可以了。 Facade模式正是这样

熊熊乐园-JAVA篇 4506

efm32 入门.pdf

本PDF共计22页,介绍的是操作驱动API,下载与否自己斟酌。

蓝牙模块HM-10手册

蓝牙模块HM-10手册,该手册对蓝牙模块HM-10进行了详细的介绍和使用方法以及一些AT指令。

代码的“门面”——模式系列谈之Facade模式(转)

看到“门面”这个词,大家一定都觉得很熟悉。不错,这个词正是借用了我们日常生活中的“门面”的概念。日常生活中的“门面”,正是我们买东西的地方。因此可以这么说,“门面”就是这么一个地方,它们跟各种商品的生产商打交道,收集商品后,再卖给我们。换句话说,如果没有“门面”,我们将不得不直接跟各种各样的生产商买商品;而有了“门面”,我们要买东西,直接跟“门面”打交道就可以了。 Facade模式正是这样...

weixin_34344403的博客 99

Camera2Demo

在Camera2 的基础上进行封装,使得Camera2一堆初始化逻辑与Activity分离,降低耦合度,完成预览拍照并保存的操作

Facade模式

Facade模式   Facade模式要求一个子系统的外部与其内部的通信必须通过一个统一的Facade对象进行。Facade模式提供一个高层次的接口,使得子系统更易于使用。 就如同医院的接待员一样,Facade模式的Facade类将客户端与子系统的内部复杂性分隔开,使得客户端只需要与Facade对象打交道,而不需要与子系统内部的很多对象打交道。 观察者模式的结构 Facade的几个要点 从客户程序的角度来看,Facade模式不仅简化了整个组件系统的接口,同时对于组件内部与外部客户程序来说,从某种程度上也达

liaowenxiong的博客 1666

java设计模式之Facade模式

介绍外观模式之前,首先让我们来看下面的例子:假设我们现有一个对外接口FacadeService,里面有一个对外的方法a();public interface FacadeService { public void a();//这个方法是给外部调用的 }他有一个实现类FacadeServiceImpl,他实现了FacadeService接口的a方法,同时又新增了一个自己的供内部调用的方法b...

一只小菜鸡 5232

Facade模式的介绍

 Facade模式http://www.diybl.com/ 2007-12-22  网络 点击:157  [ 评论 ]--文章搜索:     【点击打包该文章】  【本站开通在线QQ讨论群】 第一次看设计模式,挺有意思参考两本书,设计模式精解和设计模式精解-GoF 23 种设计模式解析附 C++实现源码FACADE 模式,正面模式?他之所以这么命名,是因为他在原系统之前放了一个新

985

设计模式:Facade模式

Facade模式——简单窗口 当调用大型程序进行处理时,我们需要格外注意那些数量庞大的类之间错综复杂的关系。不过有一种更简单的做法,就是为这个大型程序提供一个“窗口”。这样,我们就不必单独地关注每个类了,只需简单地对“窗口”提出请求即可。 这个“窗口”就是Facade模式。使用Facade模式可以为相互关联在一起的错综复杂的类整理出高层接口(API)。其中的Facade角色可以让系统对外只有一...

每一个不曾起舞的日子,都是对人生的辜负。 6042

Facade 模式

Facade 模式 使用Facade模式可以为互相关联在一起的错综复杂的类整理出高层接口(API)。其中的Facade角色可以让系统对外只有一个简单的接口(API)。而且,Facade角色还会考虑系统内部各个类之间的责任关系和依赖关系,按照正确的顺序调用各个类。 示例程序 示例程序类图 Database mport java.io.FileInputStream; import java.io....

stepMore的博客 581

设计模式——Facade(外观)模式

目录前言1 定义2 适用性3 结构3.1 结构图3.2 参与者4 Spring实际应用举例4.1 Client——我们定义的启动类4.2 Facade——SpringApplication.run()方法4.3 subSystem——ResourceLoader5 总结参考文献 前言 我们通常会遇到调用一个复杂子系统,而当这个子系统进行更新或其它改进时,将不可避免的影响我们的代码。而Facade就是一种可以帮助我们对复杂子系统进行解耦的一种模式。 1 定义 Facade模式:为子系统中的一组接口提供一个一

qq_36566262的博客 7584

Facade (外观)模式

15.1 Facade 模式   程序总是会变得越来越大。随着时间的推移,程序中的类会越来越多,而且它们之间相互关联,这会导致程序结构也会变得越来越复杂。我们在使用这些类之前,必须先弄清楚它们之间的关系,注意正确的调用顺序。   不过与其这么做,不如为这个大型程序准备一个“窗口”。这样,我们就不必单独地关注每个类了,只需简单地对 “窗口” 提出请求即可。   使用 Facade 模式可以为互相关联...

矢落叶の博客 707

外观(Facade)模式

外观模式 为子系统提供一个一致的接口,此模式定义了一个高层接口,使得子系统更加容易使用。 子系统将多个接口进行综合管理。 举个栗子: 假设我们要做股票,我们就需要去学股票的知识,我们可以找基金,让其帮我们做投资。而基金就懂得各种理财知识。 此时基金对我们用户就是Facade,做股票,做期货,做货币这些子系统,Facade是对这些子系统的接口的集合。 Facade 中拥有所有子系统的对象。facad...

不吐泡泡的咸鱼 280

Adapter模式与Facade模式的比较

Adapter是需要满足一个已经存在于新系统设计中的接口。而Facade不必遵守这一点。Adapter提供的接口可以是 既存系统暴露的接口的子集,当然,也可以是超集。而Facade提供的接口,一定是既存系统的一个子集。换句话说,Adapter模式提供的接口上的功能,可能是既存系统中不存在的,而Facade模式提供的接口上的功能,一定是既存系统中存在的。下面是一个Adapter模式的范例代码priv

凤凰的专栏 1066
上一篇: 设计模式总结
下一篇: Mac下的Subversion使用文档
sheltonwan
博客等级 码龄20年 77粉丝 79原创
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值