文档介绍：该【研磨设计模式之工厂方法模式精编版 】是由【haha】上传分享，文档一共【27】页，该文档可以免费在线阅读，需要了解更多关于【研磨设计模式之工厂方法模式精编版 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。研磨设计模式之工厂方
法模式
文件编码(008-TTIG-UTITD-GKBTT-PUUTI-WYTUI-8256)
做Java一晃就十年了,最近手痒痒,也决定跟随一下潮流,整个博客,写
点东西,就算对自己的知识进行一个梳理和总结,也跟朋友们交流交流,
希望能坚持下去。先写写设计模式方面的内容吧,就是GoF的23个模
式,先从大家最熟悉的工厂方法模式开始,这个最简单,明白的人多,
看看是否能写出点跟别人不一样的东西,欢迎大家来热烈讨论,提出建
议或意见,并进行批评指正,一概虚心接受,在此先谢过了!另外,
大家也可以说说最想看到哪个模式,那我就先写它,呵呵,大家感兴
趣,我才会有动力写下去!好了,言归正传,NowGo!
工厂方法模式(FactoryMethod)
1场景问题
导出数据的应用框架
考虑这样一个实际应用:实现一个导出数据的应用框架,来让客户选择
数据的导出方式,并真正执行数据导出。在一些实际的企业应用中,一
个公司的系统往往分散在很多个不同的地方运行,比如各个分公司或者
是门市点,公司没有建立全公司专网的实力,但是又不愿意让业务数据
实时的在广域网上传递,一个是考虑数据安全的问题,一个是运行速度
的问题。这种系统通常会有一个折中的方案,那就是各个分公司内运行
系统的时候是独立的,是在自己分公司的局域网内运行。然后在每天业
务结束的时候,各个分公司会导出自己的业务数据,然后把业务数据打
包通过网络传送给总公司,或是专人把数据送到总公司,然后由总公司
由于框架完成了一定的功能,而且通常是一些基础的、有难度的、通用
的功能,这就避免我们在应用开发的时候完全从头开始,而是在框架已
有的功能之上继续开发,也就是说会复用框架的功能,从而加快应用的
开发进度。
给我们一个精良的程序架构
框架定义了应用的整体结构,包括类和对象的分割,各部分的主要责
任,类和对象怎么协作,以及控制流程等等。现在Java界大多数流行的
框架,大都出自大师手笔,设计都很精良。基于这样的框架来开发,一
般会遵循框架已经规划好的结构来进行开发,从而让我们开发的应用程
序的结构也相对变得精良了。
(3):对框架的理解
基于框架来开发,事情还是那些事情,只是看谁做的问题
对于应用程序和框架的关系,可以用一个图来简单描述一下,如图1所
示:
图1应用程序和框架的简单关系示意图
如果没有框架,那么客户要求的所有功能都由开发人员自己来开发,没
问题,同样可以实现用户要求的功能,只是开发人员的工作多点。如果
有了框架,框架本身完成了一定的功能,那么框架已有的功能,开发人
员就可以不做了,开发人员只需要完成框架没有的功能,最后同样是完
成客户要求的所有功能,但是开发人员的工作就减少了。也就是说,基
于框架来开发,软件要完成的功能并没有变化,还是客户要求的所有功
能,也就是“事情还是那些事情”的意思。但是有了框架过后,框架完
成了一部分功能,然后开发人员再完成一部分功能,最后由框架和开发
人员合起来完成了整个软件的功能,也就是看这些功能“由谁做”的问
题。
基于框架开发,可以不去做框架所做的事情,但是应该明白框架在干什
么,以及框架是如何实现相应功能的事实上,在实际开发中,应用程序
和框架的关系,通常都不会如上面讲述的那样,分得那么清楚,更为普
遍的是相互交互的,也就是应用程序做一部分工作,然后框架做一部分
工作,然后应用程序再做一部分工作,然后框架再做一部分工作,如此
交错,最后由应用程序和框架组合起来完成用户的功能要求。也用个图
来说明,如图2所示:
图2应用程序和框架的关系示意图
如果把这个由应用程序和框架组合在一起构成的矩形,当作最后完成的
软件。试想一下,如果你不懂框架在干什么的话,相当于框架对你来讲
是个黑盒,也就是相当于在上面图2中,去掉框架的两块,会发现什么
没错,剩下的应用程序是支离破碎的,是相互分隔开来的。这会导致一
个非常致命的问题,整个应用是如何运转起来的,你是不清楚的,也就
是说对你而言,项目已经失控了,从项目管理的角度来讲,这是很危险
的。因此,在基于框架开发的时候,虽然我们可以不去做框架所做的事
情,但是应该搞明白框架在干什么,如果条件许可的话,还应该搞清楚
框架是如何实现相应功能的,至少应该把大致的实现思路和实现步骤搞
清楚,这样我们才能整体的掌控整个项目,才能尽量减少出现项目失控
的情况。
(4):框架和设计模式的关系
设计模式比框架更抽象
框架已经是实现出来的软件了,虽然只是个半成品的软件,但毕竟是已
经实现出来的了。而设计模式的重心还在于解决问题的方案上,也就是
还停留在思想的层面。因此设计模式比框架更为抽象。
设计模式是比框架更小的体系结构元素
如上所述,框架是已经实现出来的软件,并实现了一系列的功能,因此
一个框架,通常会包含多个设计模式的应用。
框架比设计模式更加特例化
框架是完成一定功能的半成品软件,也就是说,框架的目的很明确,就
是要解决某一个领域的某些问题,那是很具体的功能,不同的领域实现
出来的框架是不一样的。而设计模式还停留在思想的层面,在不同的领
域都可以应用,只要相应的问题适合用某个设计模式来解决。因此框架
总是针对特定领域的,而设计模式更加注重从思想上,从方法上来解决
问题,更加通用化。
有何问题
分析上面要实现的应用框架,不管用户选择什么样的导出格式,最后导
出的都是一个文件,而且系统并不知道究竟要导出成为什么样的文件,
因此应该有一个统一的接口,来描述系统最后生成的对象,并操作输出
的文件。先把导出的文件对象的接口定义出来,示例代码如下:
/**
*导出的文件对象的接口
*/
publicinterfaceExportFileApi{
/**
*导出内容成为文件
****@paramdata示意:需要保存的数据
****@return是否导出成功
*/
publicbooleanexport(Stringdata);
}
对于实现导出数据的业务功能对象,它应该根据需要来创建相应的
ExportFileApi的实现对象,因为特定的ExportFileApi的实现是与具体
的业务相关的。但是对于实现导出数据的业务功能对象而言,它并不知
道应该创建哪一个ExportFileApi的实现对象,也不知道如何创建。
也就是说:对于实现导出数据的业务功能对象,它需要创建
ExportFileApi的具体实例对象,但是它只知道ExportFileApi接口,而
不知道其具体的实现。那该怎么办呢
2解决方案
工厂方法模式来解决
用来解决上述问题的一个合理的解决方案就是工厂方法模式。那么什么
是工厂方法模式呢
(1)工厂方法模式定义定义一个用于创建对象的接口,让子类决定实
例化哪一个类,FactoryMethod使一个类的实例化延迟到其子类。
(2)应用工厂方法模式来解决的思路
仔细分析上面的问题,事实上在实现导出数据的业务功能对象里面,根
本就不知道究竟要使用哪一种导出文件的格式,因此这个对象本就不应
该和具体的导出文件的对象耦合在一起,它只需要面向导出的文件对象
的接口就好了。但是这样一来,又有新的问题产生了:接口是不能直接
使用的,需要使用具体的接口实现对象的实例。这不是自相矛盾吗要求
面向接口,不让和具体的实现耦合,但是又需要创建接口的具体实现对
象的实例。怎么解决这个矛盾呢
工厂方法模式的解决思路很有意思,那就是不解决,采取无为而治的方
式:不是需要接口对象吗,那就定义一个方法来创建;可是事实上它自
己是不知道如何创建这个接口对象的,没有关系,那就定义成抽象方法
就好了,自己实现不了,那就让子类来实现,这样这个对象本身就可以
只是面向接口编程,而无需关心到底如何创建接口对象了。
模式结构和说明
工厂方法模式的结构如图3所示:
图3工厂方法模式
结构示意图
Product:
定义工厂方法所创建的对象的接口,也就是实际需要使用的对象的接
口。
ConcreteProduct:
具体的Product接口的实现对象。
Creator:
创建器,声明工厂方法,工厂方法通常会返回一个Product类型的实例
对象,而且多是抽象方法。也可以在Creator里面提供工厂方法的默认
实现,让工厂方法返回一个缺省的Product类型的实例对象。
ConcreteCreator:具体的创建器对象,覆盖实现Creator定义的工厂
方法,返回具体的Product实例。
工厂方法模式示例代码
(1)先看看Product的定义,示例代码如下:
/**
*工厂方法所创建的对象的接口
*/
publicinterfaceProduct{