uml设计模式三个工厂类图代码详解

合集下载

实验五 工厂方法模式、抽象工厂模式和生成器模式

实验五 工厂方法模式、抽象工厂模式和生成器模式

实验五工厂方法模式、抽象工厂模式和生成器模式的应用一、实验目的通过该实验,理解工厂方法模式、抽象工厂模式和生成器模式的意图、结构,在软件开发中使用这些模式并进行功能验证。

二、实验内容1.手机工厂:现实中不同品牌的手机应由不同的工厂制造,使用工厂方法模式模拟实现。

图1 手机工厂的类图2.微型计算机配件的生产:该系统所需要的产品族有两个:PC系列和MAC系列,产品等级结构也有两个:RAM和CPU,使用抽象工厂模式模拟实现。

图2 微型计算机配件生产系统的设计类图3.用程序画一个小人:要求小人要有头、身体、手和脚。

使用生成器模式模拟实现。

图3 利用程序画小人的类图三、实验步骤与要求1.对于以上题目要认真分析和理解题意,程序中要求使用相应的模式。

2.上机录入,使用JDK编译器调试、运行、验证程序。

3.请指导教师审查程序和运行结果并评定成绩;4.撰写并上交实验报告。

四、实验原理:1、工厂方法模式当系统准备为用户提供某个类的子类的实例,又不想让用户代码和该子类形成耦合时,可以使用工厂方法模式来设计系统。

工厂方法模式的关键是在一个接口或抽象类中定义一个抽象方法,该方法返回某个类的子类的实例,该抽象类或接口让其子类或实现该接口的类通过重写这个抽象方法返回某个子类的实例。

适合使用工厂方法模式的情景有:●用户需要一个类的子类的实例,但不希望与该类的子类形成耦合●用户需要一个类的子类的实例,但用户不知道该类有哪些子类可用。

工厂方法模式的UML类图:图4 工厂方法模式的类图2、抽象工厂模式当系统准备为用户提供一系列相关的对象,又不想让用户代码和创建这些对象的类形成耦合时,就可以使用抽象工厂模式来设计系统。

抽象工厂模式的关键是在一个抽象类或接口中定义若干个抽象方法,这些抽象方法分别返回某个类的实例,该抽象类或接口让其子类或实现该接口的类重写这些抽象方法为用户提供一系列相关的对象。

适合使用抽象工厂模式的情景有:●系统需要为用户提供多个对象,但不希望用户直接使用new运算符实例化这些对象,即希望用户和创建对象的类解耦。

UML科普文,一篇文章掌握14种UML图

UML科普文,一篇文章掌握14种UML图

UML科普⽂,⼀篇⽂章掌握14种UML图前⾔上⼀篇⽂章写了⼀篇建造者模式,其中有⼏个UML类图,有的读者反馈看不懂了,我们今天就来解决⼀哈。

什么是UML?UML是Unified Model Language的缩写,中⽂是统⼀建模语⾔,是由⼀整套图表组成的标准化建模语⾔。

为什么要⽤UML?通过使⽤UML使得在软件开发之前,对整个软件设计有更好的可读性,可理解性,从⽽降低开发风险。

同时,也能⽅便各个开发⼈员之间的交流。

UML提供了极富表达能⼒的建模语⾔,可以让软件开发过程中的不同⼈员分别得到⾃⼰感兴趣的信息。

Page-Jones 在《Fundamental Object-Oriented Design in UML》⼀书中总结了UML的主要⽬的,如下:1. 为⽤户提供现成的、有表现⼒的可视化建模语⾔,以便他们开发和交换有意义的模型。

2. 为核⼼概念提供可扩展性 (Extensibility) 和特殊化 (Specialization) 机制。

3. 独⽴于特定的编程语⾔和开发过程。

4. 为了解建模语⾔提供⼀个正式的基础。

5. ⿎励⾯向对象⼯具市场的发展。

6. ⽀持更⾼层次的开发概念,如协作,框架,模式和组件。

7. 整合最佳的⼯作⽅法 (Best Practices)。

UML图有哪些?UML图分为结构图和⾏为图。

结构图分为类图、轮廓图、组件图、组合结构图、对象图、部署图、包图。

⾏为图⼜分活动图、⽤例图、状态机图和交互图。

交互图⼜分为序列图、时序图、通讯图、交互概览图。

UML图概览什么是类图?【概念】类图是⼀切⾯向对象⽅法的核⼼建模⼯具。

类图描述了系统中对象的类型以及它们之间存在的各种静态关系。

【⽬的】⽤来表⽰类、接⼝以及它们之间的静态结构和关系。

在类图中,常见的有以下⼏种关系。

泛化(Generalization)【泛化关系】是⼀种继承关系,表⽰⼦类继承⽗类的所有特征和⾏为。

【箭头指向】带三⾓箭头的实线,箭头指向⽗类。

UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明书画法和功能

UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明书画法和功能

UML各种图例面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML(也就是Unified Modeling Language ™),这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标,即:∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题,测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题,我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂,设计师和施工人员之间的交流就越重要.蓝图就成标准文档为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂,参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师,设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师,设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的,它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事(属性attributes)和他们可以做的事(行为或操作behaviors or operations).对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性(数据)和行为(方法或函数).对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间,并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association(或简称通讯communication)标准文档角色是人状的图标,用例是一个椭圆,通讯是连接角色和用例的线.一个用例图是角色,用例,和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.决定特征(需求).当系统已经分析好并且设计成型时,新的用例产生新的需求标准文档∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的-它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式:Cash,Check,或者Credit.订单包括OrderDetails(line item),每个这种类都连着Item.标准文档UML类的符号是一个被划分成三块的方框:类名,属性,和操作.抽象类的名字,像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association-表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中,关联用两个类之间的连线表示.标准文档标准文档为了简单地表示出复杂的类图,可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型.dependencies关系.如果另一个的包B改变可能会导致一个包A改变,则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时(特别是递归关系时)很有用.这个类图示一个大学的Department可以包括其他很多的Departments.标准文档这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚,类或实例名可以在对象图中被省略.标准文档每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴,时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时,角色用一条虚线表示,当对象的过程处于激活状态时,生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.标准文档协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息,但他们不关心什么时候消息被传递,只关心对象的角色.在序列图中,对象的角色放在上面而消息则是连接线.标准文档对象角色矩形上标有类或对象名(或者都有).类名前面有个冒号(:).协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息(也就是同一个调用中的消息)有同样的数字前缀,再根据他们出现的顺序增加一个后缀1,2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.标准文档我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号,再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态:Getting SSN, Getting PIN, Validating, 以及 Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.标准文档状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN,另一个则在上Getting PIN.初始状态(黑色圆圈)是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用(/动作)表示.当进入Validating状态时,对象并不等外部事件触发转移.取而代之,它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上,而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说,我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和 Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.标准文档标准文档标准文档。

UML类图画法全程解析

UML类图画法全程解析

UML类图画法全程解析本节向⼤家介绍⼀下UML类图画法,主要包括UML类图元素和关系画法,希望通过本⽂的介绍,你对UML类图画法有⼀定的认识。

软件设计起步:UML类图画法学习设计模式,画UML类图是基础,通过UML类图,能更好地和⼤家交流,也能很容易就表达出⾃⼰的设计想法,它就好⽐普通话,是⼀种标准语⾔。

现在流⾏的主要⼯具有两种:RationalRose和MicrosoftVisio,这两种⼯具都⽐较易⽤,选择哪种⼯具就看个⼈的喜好了。

本⼈对Microsoft 的软件⽐较有好感,所以⾃然MicrosoftVisio2003是我的⾸选。

UML类图常⽤元素。

类:类是⼀种复杂的数据类型,它是将不同类型的数据和与这些数据相关的操作封装在⼀起的集合体。

CPerson是⼀个抽象类,它是不能被实例化的,⽽CFamily可以被实例化。

接⼝:接⼝是被调⽤者调⽤的⼀组操作⽅法。

其实CPerson也可以作为接⼝。

UML类图中常见的⼏种关系。

泛化(Generalization):⼀句话,就是继承的表⽰。

是is-a的关系。

依赖(Dependency):UML类图画法中依赖是⼀种使⽤关系,它说明⼀个事物规范的变化可能影响到使⽤它的另⼀个事务,但反之则不然。

依赖关系的表⽰法是虚线箭头,箭头尾部的元素依赖箭头头部的元素,是use-a的关系。

关联(Association):⽤于描述类与类之间的连接,是has-a的关系。

聚合(Aggregation):聚合是关联的特例。

如果类与类之间的关系具有“整体和局部”的特点,则把这样的关联称为聚合。

它往往有“包含”,“由……组成”的意思。

我这⾥举的都是平时UML类图画法常⽤的⼏种情况,当然UML还有很多知识我没有了解,⽐如关联就有许多种。

本节向⼤家介绍⼀下UML类图符号,只有掌握了UML符号的意义,你才能很好的使⽤,本节从⼋个⽅⾯向⼤家介绍UML类图符号,希望通过本节的学习你对UML类图符号有初步的认识。

UML类图详细教程

UML类图详细教程

2021/2/4
类的图形表示和示例
4
在类图中,根据建模的不同景象,类图标中不一定列出全部的
内容。如在建立分析模型或设计模型时,甚至可以只列出类名, 在图中着重表达的是类与类之间的联系;在建立实现 模型时,则应当在类图标中详细给出类的属性和方法等细节。
2021/2/4
5
1. 属性
属性(Attribute)在UML类图标的矩形框中用文字串说明,如 下图所示。
UML类图详细教程
4.1 UML基本类图
面向对象设计的基础就是使用类。类是用来代表现实事务或 者功能的构造块。在本节中,我们将要学习如何建模类及其相互 之间的关系,以便在编写代码之前让你对系统拥有全面的认识。
类图是由若干类关联在一起,反映系统或者子系统组成结构的 静态图。类图的建模贯穿工程的分析和设计阶段的始终,通常从 商务伙伴能够理解的类开始建模,最终往往成为只有开发小组才 能够完全理解的类。
displays
1
Administrator
OnlineUser
WebSite
use
+ UserName : String = ""
# Password : String = ""
+ Logon() + View()
2021/2/4
45
练习: 建模一个类图
在这个练习中,将会从用例图建模一个类图。读者应该遵循
•若可视性标记为“-”或“ private”,则为私用属性,不可以被外部 对象访问,只能为本类的对象使用。
•可视性可以缺省,表示该属性不可视。Leabharlann 2021/2/47
Student类
2021/2/4

UML中数据流图,用例图,类图,对象图,角色图,活动图,序列图详细讲述保存供参考

UML中数据流图,用例图,类图,对象图,角色图,活动图,序列图详细讲述保存供参考

UML中数据流图,⽤例图,类图,对象图,⾓⾊图,活动图,序列图详细讲述保存供参考这个⽂章,是我在急需的情况下在园⼦⾥搜索到的,原创作者是:DO-websoftware,为了⾃⼰看⽅便,所以复制到我的空间,希望原创者不要介意哦~~~~很详细的介绍,对我的帮助很⼤,谢谢哦。

类图,对象图,⾓⾊图:⼀、UML中基本的图范畴:在 UML 2 中有⼆种基本的图范畴:结构图和⾏为图。

每个 UML 图都属于这⼆个图范畴。

结构图的⽬的是显⽰建模系统的静态结构。

它们包括类,组件和(或)对象图。

另⼀⽅⾯,⾏为图显⽰系统中的对象的动态⾏为,包括如对象的⽅法,协作和活动之类的内容。

⾏为图的实例是活动图,⽤例图和序列图。

⼆、UML中的类图:1.类图的表⽰:类的 UML 表⽰是⼀个长⽅形,垂直地分为三个区,如图 1 所⽰。

顶部区域显⽰类的名字。

中间的区域列出类的属性。

底部的区域列出类的操作。

在⼀个类图上画⼀个类元素时,你必须要有顶端的区域,下⾯的⼆个区域是可选择的(当图描述仅仅⽤于显⽰分类器间关系的⾼层细节时,下⾯的两个区域是不必要的)。

描述:顶部区域显⽰类的名字。

中间的区域列出类的属性。

底部的区域列出类的操作。

当在⼀个类图上画⼀个类元素时,你必须要有顶端的区域,下⾯的⼆个区域是可选择的(当图描述仅仅⽤于显⽰分类器间关系的⾼层细节时,下⾯的两个区域是不必要的)。

·类名:如果是抽象类,则采⽤斜体·类属性列表:name : attribute type 如 flightNumber : Integer,这是最常见的表达形式name : attribute type = default value 如 balance : Dollars = 0,这是带有默认值的表达形式·类⽅法列表:name(parameter list) : type of value returned注意:在业务类图中,属性类型通常与单位相符,这对于图的可能读者是有意义的(例如,分钟,美元,等等)。

03.设计模式.UML类图

03.设计模式.UML类图

UML(Unified Modeling Language,统一建模语言)。
武汉科技大学

UML简介
UML的诞生
1997年11月,在Ivar Jacoboson、Grady Booch以及James Rumbaugh的共同努力下,UML1.1版本提交给OMG (Object Management Group, 对象管理组织)并获得通 过,UML1.1成为业界标准的建模语言。
Ivar Jacobson博士曾任瑞典爱立信公司的首席软 件体系架构师,负责迄今为止商业上最为成功 的AXE交换机的研发。
Байду номын сангаас
Jacobson《面向对象软件工程》和《UML 语言 用户指南》等著作,已经成为殿堂级的软件经 典著作。
武汉科技大学

UML简介
UML的诞生
从1994年起,Grady Booch和James Rumbaugh在Rational 软件公司开始了UML的创建工作。 1995年,OOSE方法和Objectory方法的创建者Ivar Jacobson也加入其中。 UML三位创始人正式联手,共同为创建一种标准的建 模语言而一起工作,他们将开发出来的产品名称定为
UML简介
武汉科技大学

UML简介
UML“三剑客”
UML是面向对象领域的三位著名的方法学家 Grady Booch,James Rumbaugh(詹姆斯-朗博) 和Ivar Jacobson (伊万· 雅各布森)共同提出的。
Grady Booch
James Rumbaugh
都拥有有影响力的发言权。截至到2010-12-30,OMG拥
有379个会员组织。
武汉科技大学

UML各种图例—用例图、类图、状态图、包图、协作图、顺序图

UML各种图例—用例图、类图、状态图、包图、协作图、顺序图

UML各种图例——用例图、类图、状态图、包图、协作图、顺序图面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML(也就是Unified Modeling Language™),这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标,即:∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题,测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题,我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂,设计师和施工人员之间的交流就越重要.蓝图就成为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂,参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师,设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师,设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的,它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事(属性attributes)和他们可以做的事(行为或操作behaviors or operations).对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性(数据)和行为(方法或函数).对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间,并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association(或简称通讯communication)角色是人状的图标,用例是一个椭圆,通讯是连接角色和用例的线.一个用例图是角色,用例,和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.∙决定特征(需求).当系统已经分析好并且设计成型时,新的用例产生新的需求∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的-它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式:Cash,Check,或者Credit.订单包括OrderDetails(line item),每个这种类都连着Item.每个类图包括类,关联和多样性表示.方向性和角色是为了使图示得更清楚时可选的项目.包和对象图为了简单地表示出复杂的类图,可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型. dependencies关系.如果另一个的包B改变可能会导致一个包A改变,则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时(特别是递归关系时)很有用.这个类图示一个大学的Department可以包括其他很多的Departments.这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚,类或实例名可以在对象图中被省略.每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴,时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时,角色用一条虚线表示,当对象的过程处于激活状态时,生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息,但他们不关心什么时候消息被传递,只关心对象的角色.在序列图中,对象的角色放在上面而消息则是连接线.对象角色矩形上标有类或对象名(或者都有).类名前面有个冒号(:).协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息(也就是同一个调用中的消息)有同样的数字前缀,再根据他们出现的顺序增加一个后缀1,2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号,再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态:Getting SSN, Getting PIN, Validating, 以及Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN,另一个则在上Getting PIN.初始状态(黑色圆圈)是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用(/动作)表示.当进入Validating状态时,对象并不等外部事件触发转移.取而代之,它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上,而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说,我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

工厂模式在《Java与模式》中分为三类:
1)简单工厂模式(Simple Factory):不利于产生系列产品;
2)工厂方法模式(Factory Method):又称为多形性工厂;
3)抽象工厂模式(Abstract Factory):又称为工具箱,产生产品族,但不利于产生新的产品;
这三种模式从上到下逐步抽象,并且更具一般性。

GOF在《设计模式》一书中将工厂模式分为两类:工厂方法模式(Factory Metho d)与抽象工厂模式(Abstract Factory)。

将简单工厂模式(Simple Factory)看为工厂方法模式的一种特例,两者归为一类。

二、简单工厂模式
简单工厂模式又称静态工厂方法模式。

重命名上就可以看出这个模式一定很简单。

它存在的目的很简单:定义一个用于创建对象的接口。

在简单工厂模式中,一个工厂类处于对产品类实例化调用的中心位置上,它决定那一个产品类应当被实例化, 如同一个交通警察站在来往的车辆流中,决定放行那一个方向的车辆向那一个方向流动一样。

先来看看它的组成:
1) 工厂类角色:这是本模式的核心,含有一定的商业逻辑和判断逻辑。

在java中它往往由一个具体类实现。

2) 抽象产品角色:它一般是具体产品继承的父类或者实现的接口。

在java中由接口或者抽象类来实现。

3) 具体产品角色:工厂类所创建的对象就是此角色的实例。

在java中由一个具体类实现。

三、工厂方法模式
工厂方法模式是简单工厂模式的进一步抽象化和推广,工厂方法模式里不再只由一个工厂类决定那一个产品类应当被实例化,这个决定被交给抽象工厂的子类去做。

来看下它的组成:
1)抽象工厂角色:这是工厂方法模式的核心,它与应用程序无关。

是具体工厂角色必须实现的接口或者必须继承的父类。

在java中它由抽象类或者接口来实现。

2)具体工厂角色:它含有和具体业务逻辑有关的代码。

由应用程序调用以创建对应的具体产品的对象。

3)抽象产品角色:它是具体产品继承的父类或者是实现的接口。

在java中一般有抽象类
或者接口来实现。

4)具体产品角色:具体工厂角色所创建的对象就是此角色的实例。

在java中由具体的类来实现。

工厂方法模式使用继承自抽象工厂角色的多个子类来代替简单工厂模式中的“上帝类”。

正如上面所说,这样便分担了对象承受的压力;而且这样使得结构变得灵活起来——当有新的产品(即暴发户的汽车)产生时,只要按照抽象产品角色、抽象工厂角色提供的合同来生成,那么就可以被客户使用,而不必去修改任何已有的代码。

可以看出工厂角色的结构也是符合开闭原则的!
代码:
//抽象产品角色
public interface Moveable {
void run();
}
//具体产品角色
public class Plane implements Moveable {
@Override
public void run() {
System.out.println("plane....");
}
}
public class Broom implements Moveable {
@Override
public void run() {
System.out.println("broom.....");
}
}
//抽象工厂
public abstract class VehicleFactory {
abstract Moveable create();
}
//具体工厂
public class PlaneFactory extends VehicleFactory{
public Moveable create() {
return new Plane();
}
}
public class BroomFactory extends VehicleFactory{
public Moveable create() {
return new Broom();
}
}
//测试类
public class Test {
public static void main(String[] args) {
VehicleFactory factory = new BroomFactory();
Moveable m = factory.create();
m.run();
}
}
可以看出工厂方法的加入,使得对象的数量成倍增长。

当产品种类非常多时,会出现大量的与之对应的工厂对象,这不是我们所希望的。

因为如果不能避免这种情况,可以考虑使用简单工厂模式与工厂方法模式相结合的方式来减少工厂类:即对于产品树上类似的种类(一般是树的叶子中互为兄弟的)使用简单工厂模式来实现。

四、简单工厂和工厂方法模式的比较
工厂方法模式和简单工厂模式在定义上的不同是很明显的。

工厂方法模式的核心是一个抽象工厂类,而不像简单工厂模式, 把核心放在一个实类上。

工厂方法模式可以允许很多实的工厂类从抽
象工厂类继承下来, 从而可以在实际上成为多个简单工厂模式的综合,从而推广了简单工厂模式。

反过来讲,简单工厂模式是由工厂方法模式退化而来。

设想如果我们非常确定一个系统只需要一
个实的工厂类, 那么就不妨把抽象工厂类合并到实的工厂类中去。

而这样一来,我们就退化到简
单工厂模式了。

五、抽象工厂模式
代码:
//抽象工厂类
public abstract class AbstractFactory {
public abstract Vehicle createVehicle();
public abstract Weapon createWeapon();
public abstract Food createFood();
}
//具体工厂类,其中Food,Vehicle,Weapon是抽象类,
public class DefaultFactory extends AbstractFactory{
@Override
public Food createFood() {
return new Apple();
}
@Override
public Vehicle createVehicle() {
return new Car();
}
@Override
public Weapon createWeapon() {
return new AK47();
}
}
//测试类
public class Test {
public static void main(String[] args) {
AbstractFactory f = new DefaultFactory();
Vehicle v = f.createVehicle();
v.run();
Weapon w = f.createWeapon();
w.shoot();
Food a = f.createFood();
a.printName();
}
}
在抽象工厂模式中,抽象产品(AbstractProduct) 可能是一个或多个,从而构成一个或多个产品族(Product Family)。

在只有一个产品族的情况下,抽象工厂模式实际上退化到工厂方法模式。

六、总结。

(1)简单工厂模式是由一个具体的类去创建其他类的实例,父类是相同的,父类是具体的。

(2)工厂方法模式是有一个抽象的父类定义公共接口,子类负责生成具体的对象,这样做的目的是将类的实例化操作延迟到子类中完成。

(3)抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口,而无须指定他们具体的类。

它针对的是有多个产品的等级结构。

而工厂方法模式针对的是一个产品的等级结构。

相关文档
最新文档