(工厂管理)J设计模式之工厂模式(F)
《设计模式》刘伟 实验参考答案

《设计模式》刘伟 实验参考答案实验 11.在某图形库 API 中提供了多种矢量图模板,用户可以基于这些矢量图创建不同的显示图形,图形库设计人员设计的初始类图如下所示:在该图形库中,每个图形类(如 Circle 、Triangle 等)的 init()方法用于初始化所创建的图形, setColor()方法用于给图形设置边框颜色,fill()方法用于给图形设置填充颜色,setSize() 方法用于设置图形的大小,display()方法用于显示图形。
客户类(Client)在使用该图形库时发现存在如下问题:① 由于在创建窗口时每次只需要使用图形库中的一种图形,因此在更换图形时需要修改客户类源代码;② 在图形库中增加并使用新的图形时需要修改客户类源代码;③ 客户类在每次使用图形对象之前需要先创建图形对象,有些图形的创建过程较为复杂,导致客户类代码冗长且难以维护。
现需要根据面向对象设计原则对该系统进行重构,要求如下:① 隔离图形的创建和使用,将图形的创建过程封装在专门的类中,客户类在使用图形时无须直接创建图形对象,甚至不需要关心具体图形类类名;② 客户类能够方便地更换图形或使用新增图形,无须针对具体图形类编程,符合开闭原则。
绘制重构之后的类图并说明在重构过程中所运用的面向对象设计原则。
参考答案: Ci rcle + + + + +in it () setColor () f ill setSize () displa y () void void void void void Trian gle + + + + +in it () setColor () f ill setSize () displa y () void void void void void Rectangl e + + + + +in it () setColor () f ill setSize () displa y () void void void void void Cl ient2.使用简单工厂模式设计一个可以创建不同几何形状(Shape),如圆形(Circle)、矩形 (Rectangle)和三角形(Triangle)等的绘图工具类,每个几何图形均具有绘制draw()和擦除erase()两个方法,要求在绘制不支持的几何图形时,抛出一个 UnsupportedShapeException 异常,绘制类图并编程模拟实现。
管理型公司大型海外工业(F)EPC项目技术风险分析[权威资料]
![管理型公司大型海外工业(F)EPC项目技术风险分析[权威资料]](https://img.taocdn.com/s3/m/8cd4371f6c175f0e7cd13762.png)
管理型公司大型海外工业(F)EPC项目技术风险分析本文档格式为WORD,感谢你的阅读。
摘要:管理型公司担任大型海外工业(F)EPC((融资)、设计、采购、施工一体化)项目总承包商时,因为项目涉及行业广泛,总承包商又没有独有的技术资源,所以将面临独有的技术合作风险。
此外,本文还将论述标准规范本土化风险、业主要求不明确引发的成本和进度风险等。
本文结合东南亚、中亚、南美地区的三个案例,分别论述相关风险,并得到一些风险化解方法。
关键词:管理型公司;海外工业(F)EPC项目;技术风险TL364 A根据工程建设项目寿命期阶段划分,及其对项目总投资的影响程度研究,前20%的工作对整个项目的影响超过85%[1]。
作为项目龙头的技术管理,其风险防范对项目的影响至关重要。
大型海外工业(F)EPC项目走出去的过程中,不仅面对不同标准规范的挑战,不明确的业主要求引发的成本及进度风险,而且面对陌生环境,无法获得如国内项目般的支持,更需要强大的技术风险管理能力推动项目顺利实现。
管理型公司作为总承包商,在承揽海外大型工业(F)EPC项目时,由于不具备某一特定行业的技术资源,技术方案、合作伙伴的选择及合作模式显得更为重要。
1 合作风险:投标前严密论证技术方案,慎重选择技术合作伙伴,明确合同责任条款1.1 东南亚地区某机加工项目该项目是此地区机械加工工业领域中最大的总承包项目,已成功取得竣工验收证书,建成了东南亚地区水平最高、机械精加工能力最强的工厂。
项目的成功实施,与所选技术方案成熟,并在国内成功运营多年不无关系。
技术转让单位始建于1958年5月,是我国“一五”期间156项重点项目之一。
此次转让的成套技术,最初由中国从德国引进,经过国内相关单位多年的努力,已连续多年生产出合格产品,具有可靠的生产工艺。
此外,国内在引进消化的基础上,相关的零部件已经国产化,为整套技术转让提供了极大的便利。
设计单位成立于1959年,拥有专业技术人员1200余人,是目前中国机械行业规模最大、专业配置最齐全、综合技术优势最强的勘察设计单位之一。
工厂设计模式在Java RMI中的应用研究

t i o n o f a r e mo t e o b j e c t a n d c a n a l s o s a v e s e r v e r ’ s r e s o u r c e s . K e y Wo r d s RMI ,f a c t o r y d e s i g n p a t t e r n ,r e mo t e o b j e c t
总第 2 8 0 期 2 0 1 3年第 2 期
计算机与数字工程
C o mp u t e r& Di g i t a l E n g i n e e r i n g
Vo 1 . 4 1 No . 2
3 07
工厂设计模 式在 J a v a RMI中的 应 用 研 究
葛
A b s t r a c t Wh e n t a k i n g a d v a n t a g e o f t h e R MI t o d e v e l o p t h e d i s t r i b u t e d a p p l i c a t i o n s , r e mo t e o b j e c t n e e d s t o b e r e g i s t e r e d i n o r d e r t o a e — c e s s .W h i l e e x c e s s i v e r e g i s t r a t i o n o f t h e r e mo t e o b j e c t b r i n g s t h e p r o b l e ms o f n a me d t e d i o u s a n d w a s t e o f s e r v e r - s i d e me mo r y .Th e r e f o r e , t h r o u g h t h e f a c t o r y d e s i g n p a t t e r n t o e n c a p s u l a t e t h e r e mo t e o b j e c t f o r a s e c o n d a r y f i n d t o a c c e s s i t ,c o mb i n e d wi t h t h e e d u c a t i o n a l ma n a g e
基于工厂模式的Spring实现

it fc a{ ne ae r r C
p bi v i I ( ; u l d B ) co H p bi v i o ( ; ul d t ) co sp
式组织和管理 Jv 应用 中的各个组件 , aa 组件之 间的依 赖关系松 耦合 , 这些都得益于 S r g p n 的核心机制 : i 依赖注入 。S r g p n 使用 i B a Fc r 作 为应用 中负责 生产 和管理各组件 的工厂 , en at y o 同时也
主程 序代 码如下 :
pbi c s at y e o{ u l l s c rD m c a F o p b c tt i i(tn ̄ag ) u l ac od n Sr g r { i s iv ma i s
App iai Co e t c= w F lS tmXm l lc t on ntx ne ie yse App ia lc —
Sp i g Re l a i s d o a t r t r r ai t n z on Ba e n F c o y Pa t n e
W a H o g in ng n xa g
( o ao aT c Hg , i nn nier g&A pi eh oo yUnvrt F xn 13 0 V ct nl ehCo ee La igE g ei i o n n p ldT cn lg iesy e i u i 0 0) 2
e r tt k rc ( ; . i Sa T a e ) pn c 1
rtr ; } eunC } p bic sF co D mo u l l s at y e { c a r p bi s t o an S ig ag) u l ti vi m i(tn[ rs { c ac d r ] C r F c r. taIs ne ” ez ) a c= at y e r t c(B n” ; 1 o gC na
如何管控工厂UPPH

如何管控工厂UPPH一、一、总体指导思想1.精益生产作为当今最为先进的制造管理方法,具有很强的实践性。
改善实施必须始终围绕精益生产管理体系的核心即消除浪费来开展各项工作,时时以精益生产思想作为工作指导的有力武器。
2.任何一项管理理论都不是一成不变的适用。
每一个企业。
在应用精益生产理论进行改善时,必须时刻结合企业所处的行业环境和企业本身的特殊性进行灵活应用,因地制宜。
只有这样,才一不至于在改善中生搬硬套,走错方向。
例如由于手机行业存在市场机会成本,战略要求不能完全做到“零库存”管理。
3.一个拥有卓越企业文化和管理的企业,需要经过多年的实践积淀才能实现。
丰田公司自成立初期就开始不断探讨生产模式,历经四十年时间才一逐步形成了初步成型的丰田方式。
时至今日,丰田方式仍在不断改善进步中。
因此,没有那个企业的实现是一瞰而就的,需要一点一滴的积累。
卓越企业管理需要系统性的全面进行改善,但需要结合实际状况分步骤分门别类的逐步改善进而达成阶段目标并最终实现总目标。
4.改善不能脱离现场。
所有数据必须现场测量,所有问题必须现场观察,充分与一线员工交流并亲身实践才能得出结论。
脱离现场,脱离实际,脱离基层员工,任何改善都只是纸上谈兵。
5.改善成果必须实现标准化,没有标准化的改善不是完美的改善。
6.精益生产的改善需要以人为本,全员参与。
只有全员参与,充分发挥人的主动性和能动性,改善才能处处开花。
7.改善是一个持续创新不断发现问题不断进步的过程。
没有最好,只有更好,持续改善,不断进步,这是丰田方式的精髓。
只有深深理解这一精髓,并将其作为企业文化融入到员工心中,才能够在精益生产的实践应用中取得长久发展。
二、实施方案指导框架结合企业自身实际状况,借鉴国内外的精益生产理论指导和实践案例研究,研究将精益生产的各钟软硬件技术进行分类,提出了新的改善模型,作为公司推行精益生产管理的指导框架。
改善模型称为新“TPS”模型,T代表技术(Technology ),P代表人员(Person ),S代表系统(System,如图4-1所示。
FMEA制作标准

FMEA製作标準第十三篇 fmea製作标準1.fmea 简介:1.1.失效模式效应分析(failure mode effect analysis, fmea)是一种系统化之工程设计帮助工具,主要是利用**方式帮忙工程师进行工程分析,使其在工程设计早期发觉潜在缺陷及其影响程度,及早谋解决之道,以避开失效之发生或降低其发生时产生之影响。
1.2.一般fmea的分析技巧主要运用在产品开发过程中, 预先分析设计及製程中的潜在故障模式, 以期提早建立各项防範及消退发生缘由之措施, 削减日后的设计变更及开发成本时间。
1.3.目前本公司使用之**及作法系以福特公司之fmea 为基础, 分为设计及製程fmea两种。
1). 设计失效模式效应分析是属于在概念定义到设计定型整个争辩开展过程中一项实质的设计机能,为求达到其效益, fmea必需协作设计发展之程式反覆进行.在执行fmea程序中需充分考虑,设计开放方式的可行性与完整性。
2). 製程fmea是将fmea技术应用于製造/组装过程之分析, 有时亦称为"过程fmea"。
过程fmea乃是在规划设计製造程式时,利用fmea技术分析制程中每一步骤可能的潜在失效模式及其影响程度,并找出每一失效模式的发生缘由与发生气率,寻求各种可能的方法以避开失效模式发生或降低其发生率,减低其影响程度,或提高製程不良之检出力气,以便在正式进入生产前就能改善其製造/组装程式,使製造不良品的机会降低,并提升製造品质。
1.4.fmea的分析物件以新产品及修改之现有产品为主, 製作时全部与被分析产品有关之部门皆需共同参与, 新产品分析时机应于概念设计阶段即开头进行, 如为修改之产品必需考虑修改前分析, 而製程段fmea则于模具及装配机未开发前进行分析, 确保达成事先充分防範之目的。
1.5.fmea 製作流程及作法叙述如下:设计段製程段1.开发专案成立后, 由专案负责人组成fmea team指定参与人员, 分派各阶段负责製作人员, 并负责协调管制之工作。
设计模式考试复习

1简单工厂模式定义:简单工厂模式是属于创建型模式,又叫做静态工厂方法(Static Factory Method)模式,但不属于23种GOF设计模式之一。
简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。
简单工厂模式是工厂模式家族中最简单实用的模式,可以理解为是不同工厂模式的一个特殊实现。
优点:工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象.通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责"消费"对象就可以了。
而不必管这些对象究竟如何创建及如何组织的.明确了各自的职责和权利,有利于整个软件体系结构的优化。
缺点:集中所有的创建逻辑,一旦不正常,整体都会受影响。
扩展相对困难。
本质:选择实现应用场景:如果想要完全封装隔离具体实现,让外部只能通过接口来操作封装体,则可以用简单工厂模式。
Uml图:实例1计算器:using System;using System.Collections.Generic; using System.Linq;using System.Text;namespace 计算器{public class Operation{private double numberA = 0; private double numberB = 0; public double NumberA{get { return numberA; } set { numberA = value; } }public double NumberB{get { return numberB; }set { numberB = value; }}public virtual double GetResult() {double result = 0;return result;}}class OperationAdd : Operation//加法类{public override double GetResult(){double result = 0;result = NumberA + NumberB;return result;}}class OperationSub : Operation//减法类 {public override double GetResult() {double result = 0;result = NumberA - NumberB;return result;}}class OperationMul : Operation//乘法类 {public override double GetResult() {double result = 0;result = NumberA * NumberB;return result;}}class OperationDiv : Operation//除法类 {public override double GetResult() {double result = 0;if (NumberB == 0)throw new Exception("除数不能为0");result = NumberA / NumberB;return result;}} public class OperationFactory{public static Operation createOperate(string operate){Operation oper = null;switch (operate){case "+":oper = new OperationAdd(); break;case "-":oper = new OperationSub(); break;case "*":oper = new OperationMul(); break;case "/":oper = new OperationDiv(); break;}return oper;}}class Program{static void Main(string[] args){Operation oper;oper =OperationFactory.createOperate("+");oper.NumberA = 1;oper.NumberB = 2;double result = oper.GetResult(); }}}2策略模式定义:它定义了算法家族,分别封装起来,让他们之间可以相互替代,此模式让算法的变化,不会影响到使用算法的用户。
简单工厂模式在实体模型单元测试中的应用

简单工厂模式在实体模型单元测试中的应用摘要:实体模型是MVC软件架构中的重要组成部分,是信息数据和业务规则的集合。
对其进行充分的单元测试是软件质量的保证。
提出了利用简单工厂模式对实体模型进行单元测试的思路。
关键词:MVC,实体模型;单元测试;设计模式;简单工厂模式0 引言在分层软件开发的思想指导下,MVC软件架构在软件系统,特别是大型的信息系统中越来越多地被采用。
而实体模型作为MVC软件架构的根基,决定着信息系统的质量,因此对其进行单元测试就显得尤为重要。
利用设计模式进行可测试实体模型的开发,可以更早和更全面地对实体模型进行单元测试,从而把缺陷危害消灭在萌芽之中。
1 MVC架构和实体模型MVC(Model-View-Controller)是一种系统架构体系,该体系是以达到降低耦合为目的而被创造出来的,它是程序员前辈们多年经验和教训的产物。
一般来说一个典型的MVC应用程序由3个被鲜明分开的层次组成:模型、视图和控制器,如图1所示。
和传统架构相比虽然MVC需要耗费较多的人力完成,但其优势证明这些花费是值得的。
视图(View):就是数据的表示层。
从最开始的windows窗口到后来的网页程序再到现在最为流行的SilverLight和flash,数据表示的方式在日新月异的发展的,这些技术提供给我们越来越丰富的感官享受。
但是万变不离其宗,其原理基本没有改变,就是接收数据并进行显示。
控制器(Controller):控制器就是模型和视图间的桥梁,它衔接着表示层和模型层,在它们之间传递着数据流和控制信息,现在的控制器渐渐发展为两种趋势,一种是“胖控制器”模式,一种是“瘦控制器”模式。
“胖控制器”模式不仅仅完成简单的数据传输和控制信息传输,还完成较为复杂的逻辑判断和事物处理,而“瘦控制器”一般只做简单的数据和控制流传输,其它的事情交由模型层完成。
模型(Model):相对应控制器层,模型层或者被称为数据层,现在也有两种形态。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Java设计模式之工厂模式(Factory) 时间:2009-08-04 17:23 来源:未知 作者:和水柔石 CSDN IE QQ 百度 我挖 Google POCO Yahoo 新浪 365Key 天极 和讯 博拉 Live 奇客 鲜果 收客 饭否 叽歪 挖客 核心提示:作者:和水柔石 一、引子 话说十年前,有一个爆发户,他家有三辆汽车(Benz (奔驰)、Bmw (宝马)、Audi (奥迪)看来这人比较爱国,没有日本车),还雇了司机为他开车。不过,爆发户坐车时总是这样:上Benz 车后跟司机说 开奔驰车! ,坐上Bmw 后他说 开
作者:和水柔石
一、引子 话说十年前,有一个爆发户,他家有三辆汽车(Benz (奔驰)、Bmw (宝马)、Audi (奥迪)看来这人比较爱国,没有日本车),还雇了司机为他开车。不过,爆发户坐车时总是这样:上Benz 车后跟司机说" 开奔驰车!" ,坐上Bmw 后他说" 开宝马车!" ,坐上Audi 后他说" 开奥迪车!" 。 你一定说:这人有病!直接说开车不就行了?! 而当把这个爆发户的行为放到我们程序语言中来,我们发现C 语言一直是通过这种方式来坐车的! 幸运的是,这种有病的现象在OO 语言中可以避免了。下面以Java 语言为基础来引入我们本文的主题:工厂模式!!
二、简介 工厂模式主要是为创建对象提供了接口。工厂模式按照《Java 与模式》中的提法分为三类: 1. 简单工厂模式(Simple Factory) 2. 工厂方法模式(Factory Method) 3. 抽象工厂模式(Abstract Factory) 这三种模式从上到下逐步抽象,并且更具一般性。还有一种分类法,就是将简单工厂模式看为工厂方法模式的一种特例,两个归为一类。下面是使用工厂模式的两种情况: 1. 在编码时不能预见需要创建哪种类的实例。 2. 系统不应依赖于产品类实例如何被创建、组合和表达的细节
三、简单工厂模式 顾名思义,这个模式本身很简单,而且使用在业务较简单的情况下。 它由三种角色组成(关系见下面的类图): 1、工厂类角色:这是本模式的核心,含有一定的商业逻辑和判断逻辑。在java 中它往往由一个具体类实现。 2、抽象产品角色:它一般是具体产品继承的父类或者实现的接口。在java 中由接口或者抽象类来实现。 3、具体产品角色:工厂类所创建的对象就是此角色的实例。在java 中由一个具体类实现。 那么简单工厂模式怎么用呢?我来举个例子吧,我想这个比讲一大段理论上的文字描述要容易理解的多!下面就来给那个暴发户治病: P 在使用了简单工厂模式后,现在暴发户只需要坐在车里对司机说句:" 开车" 就可以了。来看看怎么实现的:
1. // 抽象产品角色 2. public interface Car{ 3. public void drive(); 4. } 5. // 具体产品角色 6. public class Benz implements Car{ 7. public void drive() { 8. System.out.println("Driving Benz "); 9. } 10. } 11. 12. public class Bmw implements Car{ 13. public void drive() { 14. System.out.println("Driving Bmw "); 15. } 16. }
。。。(奥迪我就不写了:P ) 1. // 工厂类角色 2. public class Driver{ 3. 4. // 工厂方法 5. // 注意 返回类型为抽象产品角色 6. public static Car driverCar(String s)throws Exception { 7. 8. // 判断逻辑,返回具体的产品角色给Client 9. if(s.equalsIgnoreCase("Benz")) return new Benz(); 10. else if(s.equalsIgnoreCase("Bmw")) 11. return new Bmw(); 12. 13. ...... 14. else throw new Exception(); 15. 。。。 16. 17. // 欢迎暴发户出场...... 18. public class Magnate{ 19. public static void main(String[] args){ 20. try{ 21. // 告诉司机我今天坐奔驰 22. Car car = Driver.driverCar("benz"); 23. // 下命令:开车 24. car.drive(); 25. 。。。
如果将所有的类放在一个文件中,请不要忘记只能有一个类被声明为public 。 程序中类之间的关系如下:
这便是简单工厂模式了。下面是其好处: 首先,使用了简单工厂模式后,我们的程序不在" 有病" ,更加符合现实中的情况;而且客户端免除了直接创建产品对象的责任,而仅仅负责" 消费" 产品(正如暴发户所为)。 下面我们从开闭原则上来分析下简单工厂模式。当暴发户增加了一辆车的时候,只要符合抽象产品制定的合同,那么只要通知工厂类知道就可以被客户使用了。那么对于产品部分来说,它是符合开闭原则的-- 对扩展开放、对修改关闭;但是工厂部分好像不太理想,因为每增加一辆车,都要在工厂类中增加相应的商业逻辑和判断逻辑,这显自然是违背开闭原则的。 对于这样的工厂类(在我们的例子中是为司机师傅),我们称它为全能类或者上帝类。 我们举的例子是最简单的情况,而在实际应用中,很可能产品是一个多层次的树状结构。由于简单工厂模式中只有一个工厂类来对应这些产品,所以这可能会把我们的上帝类坏了,进而累坏了我们可爱的程序员:( 正如我前面提到的简单工厂模式适用于业务将简单的情况下。而对于复杂的业务环境可能不太适应阿。这就应该由工厂方法模式来出场了!!
四、工厂方法模式 先来看下它的组成吧: 1、抽象工厂角色:这是工厂方法模式的核心,它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java 中它由抽象类或者接口来实现。 2、具体工厂角色:它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。在java 中它由具体的类来实现。 3、抽象产品角色:它是具体产品继承的父类或者是实现的接口。在java 中一般有抽象类或者接口来实现。 4、具体产品角色:具体工厂角色所创建的对象就是此角色的实例。在java 中由具体的类来实现。 来用类图来清晰的表示下的它们之间的关系: 我们还是老规矩使用一个完整的例子来看看工厂模式各个角色之间是如何来协调的。话说暴发户生意越做越大,自己的爱车也越来越多。这可苦了那位司机师傅了,什么车它都要记得,维护,都要经过他来使用!于是暴发户同情他说:看你跟我这么多年的份上,以后你不用这么辛苦了,我给你分配几个人手,你只管管好他们就行了!于是,工厂方法模式的管理出现了。代码如下:
1. // 抽象产品角色,具体产品角色与简单工厂模式类似,只是变得复杂了些,这里略。 2. // 抽象工厂角色 3. public interface Driver{ 4. public Car driverCar(); 5. } 6. public class BenzDriver implements Driver{ 7. public Car driverCar(){ 8. return new Benz(); 9. } 10. } 11. public class BmwDriver implements Driver{ 12. public Car driverCar() { 13. return new Bmw(); 14. } 15. } 16. ......// 应该和具体产品形成对应关系,这里略... 17. // 有请暴发户先生 18. public class Magnate 19. { 20. public static void main(String[] args) 21. { 22. try{ 23. Driver driver = new BenzDriver(); 24. 25. Car car = driver.driverCar(); 26. car.drive(); 27. }catch(Exception e) 28. { } 29. } 30. }
工厂方法使用一个抽象工厂角色作为核心来代替在简单工厂模式中使用具体类作为核心。让我们来看看工厂方法模式给我们带来了什么?使用开闭原则来分析下工厂方法模式。当有新的产品(即暴发户的汽车)产生时,只要按照抽象产品角色、抽象工厂角色提供的合同来生成,那么就可以被客户使用,而不必去修改任何已有的代码。看来,工厂方法模式是完全符合开闭原则的! 使用工厂方法模式足以应付我们可能遇到的大部分业务需求。但是当产品种类非常多时,就会出现大量的与之对应的工厂类,这不应该是我们所希望的。所以我建议在这种情况下使用简单工厂模式与工厂方法模式相结合的方式来减少工厂类:即对于产品树上类似的种类(一般是树的叶子中互为兄弟的)使用简单工厂模式来实现。 当然特殊的情况,就要特殊对待了:对于系统中存在不同的产品树,而且产品树上存在产品族,那么这种情况下就可能可以使用抽象工厂模式了。
五、小结 让我们来看看简单工厂模式、工厂方法模式给我们的启迪: 如果不使用工厂模式来实现我们的例子,也许代码会减少很多-- 只需要实现已有的车,不使用多态。但是在可维护性上,可扩展性上是非常差的(你可以想象一下,添加一辆车后要牵动的类)。因此为了提高扩展性和维护性,多写些代码是值得的。
六、抽象工厂模式 先来认识下什么是产品族:位于不同产品等级结构中,功能相关联的产品组成的家族。如果光看这句话就能清楚的理解这个概念,我不得不佩服你啊。还是让我们用一个例子来形象地说明一下吧。
图中的BmwCar 和BenzCar 就是两个产品树(产品层次结构);而如图所示的BenzSportsCar 和BmwSportsCar 就是一个产品族。他们都可以放到跑车家族中,因此功能有所关联。同理BmwBussinessCar 和BenzSportsCar 也是一个产品族。 回到抽象产品模式的话题上,可以这么说,它和工厂方法模式的区别就在于需要创建对象的复杂程度上。而且抽象工厂模式是三个里面最为抽象、最具一般性的。抽象工厂模式的用意为:给客户端提供一个接口,可以创建多个产品族中的产品对象。而且使用抽象工厂模式还要满足一下条件: 1. 系统中有多个产品族,而系统一次只可能消费其中一族产品 2. 同属于同一个产品族的产品以其使用。 来看看抽象工厂模式的各个角色(和工厂方法的如出一辙): 抽象工厂角色:这是工厂方法模式的核心,它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java 中它由抽象类或者接口来实现。 具体工厂角色:它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。在java 中它由具体的类来实现。 抽象产品角色:它是具体产品继承的父类或者是实现的接口。在java 中一般有抽象类或者接口来实现。 具体产品角色:具体工厂角色所创建的对象就是此角色的实例。在java 中由具体的类来实现。