uml设计模式三个工厂类图代码详解
- 格式:docx
- 大小:20.58 KB
- 文档页数:4
实验五工厂方法模式、抽象工厂模式和生成器模式的应用一、实验目的通过该实验,理解工厂方法模式、抽象工厂模式和生成器模式的意图、结构,在软件开发中使用这些模式并进行功能验证。
二、实验内容1.手机工厂:现实中不同品牌的手机应由不同的工厂制造,使用工厂方法模式模拟实现。
图1 手机工厂的类图2.微型计算机配件的生产:该系统所需要的产品族有两个:PC系列和MAC系列,产品等级结构也有两个:RAM和CPU,使用抽象工厂模式模拟实现。
图2 微型计算机配件生产系统的设计类图3.用程序画一个小人:要求小人要有头、身体、手和脚。
使用生成器模式模拟实现。
图3 利用程序画小人的类图三、实验步骤与要求1.对于以上题目要认真分析和理解题意,程序中要求使用相应的模式。
2.上机录入,使用JDK编译器调试、运行、验证程序。
3.请指导教师审查程序和运行结果并评定成绩;4.撰写并上交实验报告。
四、实验原理:1、工厂方法模式当系统准备为用户提供某个类的子类的实例,又不想让用户代码和该子类形成耦合时,可以使用工厂方法模式来设计系统。
工厂方法模式的关键是在一个接口或抽象类中定义一个抽象方法,该方法返回某个类的子类的实例,该抽象类或接口让其子类或实现该接口的类通过重写这个抽象方法返回某个子类的实例。
适合使用工厂方法模式的情景有:●用户需要一个类的子类的实例,但不希望与该类的子类形成耦合●用户需要一个类的子类的实例,但用户不知道该类有哪些子类可用。
工厂方法模式的UML类图:图4 工厂方法模式的类图2、抽象工厂模式当系统准备为用户提供一系列相关的对象,又不想让用户代码和创建这些对象的类形成耦合时,就可以使用抽象工厂模式来设计系统。
抽象工厂模式的关键是在一个抽象类或接口中定义若干个抽象方法,这些抽象方法分别返回某个类的实例,该抽象类或接口让其子类或实现该接口的类重写这些抽象方法为用户提供一系列相关的对象。
适合使用抽象工厂模式的情景有:●系统需要为用户提供多个对象,但不希望用户直接使用new运算符实例化这些对象,即希望用户和创建对象的类解耦。
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(也就是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类图,能更好地和⼤家交流,也能很容易就表达出⾃⼰的设计想法,它就好⽐普通话,是⼀种标准语⾔。
现在流⾏的主要⼯具有两种: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中数据流图,⽤例图,类图,对象图,⾓⾊图,活动图,序列图详细讲述保存供参考这个⽂章,是我在急需的情况下在园⼦⾥搜索到的,原创作者是: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注意:在业务类图中,属性类型通常与单位相符,这对于图的可能读者是有意义的(例如,分钟,美元,等等)。
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.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.。
UML的类图关系分为:关联、聚合组合、依赖、泛化(继承)UML的类图关系分为:关联、聚合/组合、依赖、泛化(继承)。
⽽其中关联⼜分为双向关联、单向关联、⾃⾝关联;下⾯就让我们⼀起来看看这些关系究竟是什么,以及它们的区别在哪⾥。
1、关联双向关联:C1-C2:指双⽅都知道对⽅的存在,都可以调⽤对⽅的公共属性和⽅法。
在GOF的设计模式书上是这样描述的:虽然在分析阶段这种关系是适⽤的,但我们觉得它对于描述设计模式内的类关系来说显得太抽象了,因为在设计阶段关联关系必须被映射为对象引⽤或指针。
对象引⽤本⾝就是有向的,更适合表达我们所讨论的那种关系。
所以这种关系在设计的时候⽐较少⽤到,关联⼀般都是有向的。
使⽤ROSE ⽣成的代码是这样的:class C1...{public:C2* theC2;};class C2...{public:C1* theC1;};双向关联在代码的表现为双⽅都拥有对⽅的⼀个指针,当然也可以是引⽤或者是值。
单向关联:C3->C4:表⽰相识关系,指C3知道C4,C3可以调⽤C4的公共属性和⽅法。
没有⽣命期的依赖。
⼀般是表⽰为⼀种引⽤。
⽣成代码如下:class C3...{public:C4* theC4;};class C4...{};单向关联的代码就表现为C3有C4的指针,⽽C4对C3⼀⽆所知。
⾃⾝关联(反⾝关联):⾃⼰引⽤⾃⼰,带着⼀个⾃⼰的引⽤。
代码如下:class C14...{public:C14* theC14;};就是在⾃⼰的内部有着⼀个⾃⾝的引⽤。
2、聚合/组合当类之间有整体-部分关系的时候,我们就可以使⽤组合或者聚合。
聚合:表⽰C9聚合C10,但是C10可以离开C9⽽独⽴存在(独⽴存在的意思是在某个应⽤的问题域中这个类的存在有意义。
这句话怎么解,请看下⾯组合⾥的解释)。
代码如下:class C9...{public:};class C10...{};组合(也有⼈称为包容):⼀般是实⼼菱形加实线箭头表⽰,如上图所⽰,表⽰的是C8被C7包容,⽽且C8不能离开C7⽽独⽴存在。
UML中的类图详解及其应用场景在软件开发过程中,UML(统一建模语言)被广泛应用于需求分析、系统设计和软件开发等各个阶段。
其中,类图作为UML的核心图表之一,用于描述系统中的类、对象以及它们之间的关系。
本文将详细介绍UML中的类图,并探讨其在实际应用中的场景。
一、类图的基本概念类图是一种静态结构图,用于表示系统中的类、接口、关联、继承、依赖等元素及其之间的关系。
在类图中,类用矩形表示,类名位于矩形顶部,类的属性位于矩形中部,类的操作(方法)位于矩形底部。
类之间的关系通过连线表示,如关联关系用实线箭头表示,继承关系用空心三角箭头表示,依赖关系用虚线箭头表示等。
二、类图的元素及其关系1. 类(Class):类是对象的抽象表示,用于描述具有相同属性和行为的一组对象。
类图中的类用矩形表示,类名位于矩形顶部。
2. 接口(Interface):接口是一组方法的集合,用于描述类的行为。
接口在类图中用带有<<interface>>标记的矩形表示。
3. 属性(Attribute):属性是类的特征,描述了类的状态。
属性在类图中用名称:类型的形式表示,例如“name:String”。
4. 操作(Operation):操作是类的行为,描述了类的方法。
操作在类图中用名称(参数列表):返回类型的形式表示,例如“getName():String”。
5. 关联关系(Association):关联关系描述了类之间的连接,表示一个类与另一个类之间的关联。
关联关系在类图中用实线箭头表示。
6. 继承关系(Inheritance):继承关系描述了类之间的继承关系,表示一个类继承自另一个类。
继承关系在类图中用空心三角箭头表示。
7. 依赖关系(Dependency):依赖关系描述了类之间的依赖关系,表示一个类依赖于另一个类。
依赖关系在类图中用虚线箭头表示。
三、类图的应用场景1. 系统设计:类图是系统设计的重要工具之一。
UML类图详解及类图设计UML中定义了⽤例图、类图、时序图、协作图等九种。
设计模式中经常会⽤到的是类图。
类是⾯向对象系统组织结构的核⼼,类可以说是对⼀组具有相同属性、操作、关系和语义的对象的抽象。
在UML中,类使⽤带有分隔线的矩形表⽰,它包含名称部分(Name)、属性部分(Attribute)和操作部分(Operation)。
其中属性的表现形式是[可见性] 属性名:类型 [=默认值]。
操作的表现形式是:[可见性] 名称(参数列表)[:返回类型]。
详细见下图。
1.类图基础属性+表⽰public-表⽰private#表⽰protected~表⽰default,也就是包权限_下划线表⽰static斜体表⽰抽象2.类之间关系在UML类图中,常见的有以下⼏种关系:泛化(Generalization):带空⼼三⾓箭头的实线来表⽰,箭头由⼦类指向⽗类实现(Realization):带空⼼的三⾓箭头的虚线来表⽰,箭头从实现类指向接⼝关联(Association):分为双向关联和单向关联,其中,双向关联可以⽤带两个箭头或者没有箭头的实线来表⽰,单向关联⽤带⼀个箭头的实线来表⽰,箭头从使⽤类指向被关联的类,还可以再关联线的两端标注⾓⾊名,补充说明它们的⾓⾊。
聚合(Aggregation),⽤带空⼼菱形的实线表⽰,菱形指向整体组合(Composition):⽤带实⼼菱形的实线来表⽰,菱形指向整体。
依赖(Dependency):使⽤带箭头的虚线表⽰,箭头从使⽤类指向被依赖的类下图为类之间的关系在UML中的图形表达式:2.1泛化泛化(Generalization)表⽰类与类之间的继承关系,接⼝与接⼝之间的继承关系,或类对接⼝的实现关系(1)继承介绍:继承表⽰是⼀个类(称为⼦类、⼦接⼝)继承另外的⼀个类(称为⽗类、⽗接⼝)的功能,并可以增加它⾃⼰的新功能的能⼒。
表⽰⽅法:继承使⽤空⼼三⾓形+实线表⽰。
⽰例:鸟类继承抽象类动物(2)实现实现表⽰⼀个class类实现interface接⼝(可以是多个)的功能。
UML类图说明1:⽰例这是⼀个使⽤UML表⽰的类图的结构,通过箭头,菱形,实线以及虚线来代表⼀些类之间的关系,后⾯将按照上⾯的例⼦⼀⼀介绍说明。
上图中,abstract 车是⼀个抽象类。
⼩汽车和⾃⾏车是继承了车的抽象类,实现了抽象类的⼀些抽象⽅法,他们之间是实现关系。
SUV继承⼩汽车,SUV和⼩汽车之间是泛化关系!轮胎,发动机和⼩汽车之间是组合关系。
学⽣和班级之间是聚会关系。
学⽣和⾝份证之间是关联关系。
学⽣和⾃⾏车之间是依赖关系。
2:具体分析2.1:泛化关系上⾯UML图中,SUV和⼩汽车之间是⼀种泛化关系,SUV is a ⼩汽车,泛化关系⽤⼀种带有空⼼的箭头来表⽰。
在代码中表现的⽅式就是继承⾮抽象类的⽅式。
2.2:实现关系上⾯UML图中,⼩汽车,⾃⾏车与抽象类车,之间是⼀种实现关系。
重要的是要继承抽象类,或者实现接⼝这种关系是实现关系,在UML类图中使⽤虚线带箭头。
在代码中表现的⽅式就是继承抽象类。
2.3:聚合关系上⾯UML图中,学⽣和班级之间是⼀种聚合关系,表⽰班级有学⽣聚合⽽来,采⽤实线空⼼菱形箭头表⽰。
与组合关系不同的是,整体和部分不是强依赖的,即使整体不存在了,部分仍然存在;例如,班级撤销了,学⽣不会消失,他们依然存在。
2.4:组合关系上⾯UML图中,轮胎,发动机和⼩汽车之间是⼀种组合关系,采⽤实线实⼼菱形箭头表⽰。
与聚合关系不同的是,整体和部分是强依赖的,即使整体不存在了,组合部分也不存在;例如,⼩汽车没有,⾃然轮胎和发动起,也不会存在了。
2.5:关联关系上⾯UML图中,学⽣和⾝份证是⼀种关联关系。
关联关系是⽤⼀条直线表⽰的;它描述不同类的对象之间的结构关系;它是⼀种静态关系,通常与运⾏状态⽆关,⼀般由常识等因素决定的;它⼀般⽤来定义对象之间静态的、天然的结构;所以,关联关系是⼀种“强关联”的关系;⽐如,乘车⼈和车票之间就是⼀种关联关系;学⽣和学校就是⼀种关联关系;2.6:依赖关系上⾯UML图中,学⽣和⾃⾏车之间是⼀种依赖关系。
UML类图在UML的静态机制中类图是一个重点,它不但是设计人员关心的核心,更是实现人员关注的核心。
建模工具也主要根据类图来产生代码。
类图在UML的9个图中占据了一个相当重要的地位。
James Rumbaugh对类的定义是:类是具有相似结构、行为和关系的一组对象的描述符。
类是面向对象系统中最重要的构造块。
类图显示了一组类、接口、协作以及他们之间的关系。
在UML中问题域最终要被逐步转化,通过类来建模,通过编程语言构建这些类从而实现系统。
类加上他们之间的关系就构成了类图,类图中还可以包含接口、包等元素,也可以包括对象、链等实例。
接口在类图中通过版型来表示<<interfac e>>,下面的介绍将主要介绍类,接口和类类似。
A. 类的UML表示类的命名尽量应用领域中的术语,应明确、无岐义,以利于相互交流和理解。
类的属性、操作中的可见性使用+、#、-分别表示public、protected、private。
B.类之间的关系类之间的关系是类图中比较复杂的内容。
有关联、聚合、组合、范化、依赖。
关联:是模型元素之间的一种语义联系,是类之间的一种很弱的联系。
关联可以有方向,可以是单向关联,也可以是双向关联。
可以给关联加上关联名来描述关联的作用。
关联两端的类也可以以某种角色参与关联,角色可以具有多重性,表示可以有多少个对象参与关联。
可以通过关联类进一步描述关联的属性、操作以及其他信息。
关联类通过一条虚线与关联连接。
对于关联可以加上一些约束,以加强关联的含义。
如下图所示:聚合是一种特殊的关联,聚合表示整体与部分的关系。
通常在定义一个整体类后,再去分析这个整体类的组成结构。
从而找出一些组成类,该整体类和组成类之间就形成了聚合关系。
例如舰队是由一系列的舰船组成。
需求描述中“包含”、“组成”、“分为….部分”等词常意味着聚合关系。
组合也是一种特殊的关联,也表示类之间整体和部分的关系,但是组合关系中部分和整体具有统一的生存期。
Python设计模式-UML-类图(ClassDiagram)简介类图是⾯向对象分析和设计的核⼼,⽤来描述系统各个模块中类与类之间、接⼝与接⼝之间、类与接⼝之间的关系,以及每个类的属性、操作等特性,⼀般在详细设计过程中实施。
类图本⾝就是现实世界的抽象,是对系统中各种概念进⾏建模,并描绘出它们之间的关系,所以类图关注的对象就是元素及元素之间的关系。
类图建模步骤 - 抽象出类实体 - 识别出类的主要属性 - 画出类之间的关系 - 对各个类进⾏分析、梳理、设计类图的元素类图中包含以下⼏种模型元素:类、接⼝、关系、协作、注释、约束、包。
类 在UML的图形表⽰中,类的表⽰法是⼀个矩形,有三格组成,分别是类名、类属性、类操作。
抽象类中的类名及抽象⽅法都⽤斜体表⽰。
- 类名:⾸字母⼤写 - 类属性:格式为可见性属性名:类型 =默认值,如-name: String 可见性包括四种: + public - private # protected * package 属性名:单字属性名⼩写;多字属性名出第⼀个单词外其余单词的⾸字母⼤写 - 类操作:格式为可见性操作名(参数):返回值类型,如+getName(): String接⼝ 在UML的图形表⽰中,接⼝的表⽰法是分为两种:圆形表⽰法和构造型表⽰法。
接⼝由两栏组成,第⼀栏顶端是接⼝名称,第⼆栏是接⼝⽅法。
接⼝⽆属性只包含操作,且没有对外可见的关联。
- 圆形表⽰法 - 构造型表⽰法关系类图中类与类之间有泛化、依赖、关联、聚合、组合关系;接⼝与接⼝之间有继承关系;类与接⼝之间有实现关系。
这些关系本⾝就是类图中的元素,⽤不同的连线表⽰。
- 泛化关系 - 依赖关系 - 关联关系 - 聚合关系 - 组合关系 - 实现关系 类图中的关系较为复杂,以下分别详述。
协作 协作是指⼀些类、接⼝、关系等元素提供的交互⾏为,能够协助其他元素执⾏活动、实现功能的辅助类。
注释 对某些类和接⼝进⾏注释。
【设计模式】第⼀篇:概述、耦合、UML、七⼤原则,详细分析总结(基于Java)迷茫了⼀周,⼀段时间重复的 CRUD ,着实让我有点烦闷,最近打算将这些技术栈系列的⽂章先暂时搁置⼀下,开启⼀个新的篇章《设计模式》,毕竟前⾯写了不少 “武功招式” 的⽂章,也该提升⼀下内功了⼀设计模式概述(⼀) 什么是设计模式设计模式,即Design Patterns,是指在软件设计中,被反复使⽤的⼀种代码设计经验。
使⽤设计模式的⽬的是为了可重⽤代码,提⾼代码的可扩展性和可维护性1995年,GoF(Gang of Four,四⼈组/四⼈帮)合作出版了《设计模式:可复⽤⾯向对象软件的基础》⼀书,收录了23种设计模式,从此树⽴了软件设计模式领域的⾥程碑,【GoF设计模式】(⼆) 为什么学习设计模式前⾯我们学习了 N 种不同的技术,但是归根结底,也只是 CRUD 与调⽤之间的堆砌,或许这个创意亦或是业务很完善、很强⼤,其中也巧妙运⽤了各种⾼效的算法,但是说⽩了,这也只是为了实现或者说解决某个问题⽽做的还有时候,两个⼈同时开发⼀款相同的产品,均满⾜了预期的需求,但是 A 的程序,不仅代码健壮性强,同时后期维护扩展更是便捷(这种感觉,我们会在后⾯具体的设计模式中愈发的感觉到)⽽ B 的代码却是⼀⾔难尽啊有⼀句话总结的⾮常好:设计模式的本质是⾯向对象设计原则的实际运⽤,是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解也就是说,毕竟像例如Java这样⾯向对象的语⾔中,如何实现⼀个可维护,可维护的代码,那必然就是要降低代码耦合度,适当复⽤代码,⽽要实现这⼀切,就需要充分的利⽤ OOP 编程的特性和思想注:下⾯第⼆⼤点补充【耦合】的相关概念,若不需要跳转第三四⼤点【UML类图及类图间的关系】/【设计模式七⼤原则】在之前我写 Spring依赖注⼊的时候【万字长⽂】 Spring框架层层递进轻松⼊门(0C和D),就是从传统开发,讲到了如何通过⼯⼚模式,以及多例到单例的改进,来⼀步步实现解耦,有兴趣的朋友可以看⼀下哈⼆什么是耦合?(⾼/低)作为⼀篇新⼿都能看懂的⽂章,开始就⼀堆 IOC AOP等专业名词扔出去,好像是不太礼貌,我得把需要铺垫的知识给⼤家尽量说⼀说,如果对这块⽐较明⽩的⼤佬,直接略过就OK了耦合,就是模块间关联的程度,每个模块之间的联系越多,也就是其耦合性越强,那么独⽴性也就越差了,所以我们在软件设计中,应该尽量做到低耦合,⾼内聚⽣活中的例⼦:家⾥有⼀条串灯,上⾯有很多灯泡,如果灯坏了,你需要将整个灯带都换掉,这就是⾼耦合的表现,因为灯和灯带之间是紧密相连,不可分割的,但是如果灯泡可以随意拆卸,并不影响整个灯带,那么这就叫做低耦合代码中的例⼦:来看⼀个多态的调⽤,前提是 B 继承 A,引⽤了很多次A a = new B();a.method();如果你想要把B变成C,就需要修改所有new B()的地⽅为new C()这也就是⾼耦合如果如果使⽤我们今天要说的 spring框架就可以⼤⼤的降低耦合A a = BeanFactory().getBean(B名称);a.method();这个时候,我们只需要将B名称改为C,同时将配置⽂件中的B改为C就可以了常见的耦合有这些分类:(⼀) 内容耦合当⼀个模块直接修改或操作另⼀个模块的数据,或者直接转⼊另⼀个模块时,就发⽣了内容耦合。
UML类图符号各种关系说明以及举例UML中描述对象和类之间相互关系的⽅式包括:依赖(Dependency),关联(Association),聚合(Aggregation),组合(Composition),泛化(Generalization),实现(Realization)等。
依赖(Dependency):元素A的变化会影响元素B,但反之不成⽴,那么B和A的关系是依赖关系,B依赖A;类属关系和实现关系在语义上讲也是依赖关系,但由于其有更特殊的⽤途,所以被单独描述。
uml中⽤带箭头的虚线表⽰Dependency关系,箭头指向被依赖元素。
泛化(Generalization):通常所说的继承(特殊个体 is kind of ⼀般个体)关系,不必多解释了。
uml中⽤带空⼼箭头的实线线表⽰Generalization关系,箭头指向⼀般个体。
实现(Realize):元素A定义⼀个约定,元素B实现这个约定,则B和A的关系是Realize,B realize A。
这个关系最常⽤于接⼝。
uml 中⽤空⼼箭头和虚线表⽰Realize关系,箭头指向定义约定的元素。
关联(Association):元素间的结构化关系,是⼀种弱关系,被关联的元素间通常可以被独⽴的考虑。
uml中⽤实线表⽰Association 关系,箭头指向被依赖元素。
聚合(Aggregation):关联关系的⼀种特例,表⽰部分和整体(整体 has a 部分)的关系。
uml中⽤带空⼼菱形头的实线表⽰Aggregation关系,菱形头指向整体。
组合(Composition):组合是聚合关系的变种,表⽰元素间更强的组合关系。
如果是组合关系,如果整体被破坏则个体⼀定会被破坏,⽽聚合的个体则可能是被多个整体所共享的,不⼀定会随着某个整体的破坏⽽被破坏。
uml中⽤带实⼼菱形头的实线表⽰Composition关系,菱形头指向整体。
1.1.1 依赖(Dependency):虚线箭头表⽰1、依赖关系也是类与类之间的联结2、依赖总是单向的。
类的uml基本表示概述及解释说明1. 引言概述:在软件开发中,类图是一种常用的UML(Unified Modeling Language,统一建模语言)工具,它以图形化的方式描述了系统中的类、属性、操作和关系等元素。
类图帮助开发人员更好地理解和设计软件系统,提供了一种可视化的方法来展示面向对象的概念、结构和行为。
文章结构:本文将围绕"类的UML基本表示"这一主题展开讨论。
文章分为五个部分:引言、类的UML基本表示、解释说明、示例分析和结论。
引言部分将介绍文章内容和目的,为读者提供一个整体了解。
接下来,我们将详细解释类的UML基本表示,包括定义、类图元素和关系类型等方面内容。
然后,我们将进一步解释说明类的表示方式、属性和操作的表示方式以及继承和关联关系的表示方式。
随后,通过实际案例进行示例分析,展示如何使用类图描述系统设计中的对象关系、进行软件架构分析以及在代码实现中应用类图。
最后,在结论部分对全文进行总结,并探讨类图在实践中的应用价值以及未来发展趋势。
目的:本文旨在帮助读者深入了解类的UML基本表示,并通过解释说明和示例分析让读者掌握如何使用类图进行软件系统设计与开发。
同时,我们也将探讨类图在实践中的应用价值,希望能激发读者对于面向对象建模的兴趣和思考,并展望类图在未来的发展方向。
以上是关于"1. 引言"部分内容的详细描述,希望能够满足您所需。
2. 类的UML基本表示2.1 定义类的UML基本表示是指使用统一建模语言(Unified Modeling Language,UML)来描述和表示系统中的类及其相关信息的方法。
UML是一种图形化的建模语言,常用于软件工程领域,它可以帮助开发人员更好地理解系统设计,并进行系统分析、架构设计和代码实现。
2.2 类图元素在类图中,类被表示为一个矩形框,框内包含类名。
除了类名外,还可以在矩形框内部显示其他关键信息,比如类的属性(Attributes)和操作(Operations)。
软件工程的23种设计模式的UML类图0 引言谈到设计模式,绝对应该一起来说说重构。
重构给我们带来了什么?除了作为对遗留代码的改进的方法,另一大意义在于,能够让我们在写程序的时候能够不需事先考虑太多的代码组织问题,当然这其中也包含了应用模式的问题。
尽管大多数开发者都已经养成了写代码前先从设计开始的习惯,但是,这种程度的设计,涉及到到大局、到总体架构、到要紧的模块划分我觉得就够了。
换句话说,这时就能写代码了。
这就得益于重构的思想了。
假如没有重构的思想,有希望获得非常高质量的代码,我们就不得不在开始写代码前考虑更多事实上并非非常稳固的代码组织及设计模式的应用问题,那开发效率当然就大打折扣了。
在重构与设计模式的合理应用之下,我们能够相对较早的开始写代码,并在功能尽早实现的同时,不断地通过重构与模式来改善我们的代码质量。
因此,下面的章节中,在谈模式的同时,我也会谈谈关于常用的这些模式的重构成本的懂得。
重构成本越高意味着,在遇到类似的问题情形的时候,我们更应该提早考虑应用对应的设计模式,而重构成本比较低则说明,类似的情形下,完全能够先怎么方便,怎么快怎么写,哪怕代码不是很优雅也没关系,回头再重构也很容易。
1 创建型1.1FactoryMethod思想:Factory Method的要紧思想是使一个类的实例化延迟到其子类。
场景:典型的应用场景如:在某个系统开发的较早阶段,有某些类的实例化过程,实例化方式可能还不是很确定,或者者实际实例化的对象(可能是需要对象的某个子类中的一个)不确定,或者者比较容易变化。
如今,假如直接将实例化过程写在某个函数中,那么通常就是if-else或者select-case代码。
假如,候选项的数目较少、类型基本确定,那么这样的if-else还是能够同意的,一旦情形变得复杂、不确定性增加,更甚至包含这个构造过程的函数所在的类包含几个甚至更多类似的函数时,这样的if-else代码就会变得比较不那么容易保护了。
工厂模式在《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)抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口,而无须指定他们具体的类。
它针对的是有多个产品的等级结构。
而工厂方法模式针对的是一个产品的等级结构。