接项目做的网站,搜索引擎营销的简称是,大连哪家做网站比较好,photoshop在线制作一、数据流图
基础知识 数据流图#xff08;Data Flow Diagram,DFD#xff09;基本图形元素#xff1a; 外部实体#xff08;External Agent#xff09; 表示存在于系统之外的对象#xff0c;用来帮助用户理解系统数据的来源和去向加工#xff08;Process#xff09;数…一、数据流图
基础知识 数据流图Data Flow Diagram,DFD基本图形元素 外部实体External Agent 表示存在于系统之外的对象用来帮助用户理解系统数据的来源和去向加工Process数据存储Data Store数据流(Data Flow) 加工、数据存储和数据流用于构建软件系统内部的数据处理模型 外部实体当前系统之外的人、物、外部系统 人病人、医生、护理人员、巴士司机、机械师、会计等物传感器、控制器、采购部门等外部系统库存管理系统等 加工把输入数据处理后得到输出数据 一个加工至少有一个输入数据流和一个输出数据流 黑洞加工只有输入没有输出白洞加工只有输出没有输入灰洞加工的输入数据不足以产生输出数据 数据流由一组固定成分的数据组成表示数据的流向 数据流的起点或终点必须有一个是加工 在DFD中数据流的流向可以有以下几种 从一个加工流向另一个加工从加工流向数据存储写从数据存储流向加工读从外部实体流向加工输入从加工流向外部实体输出
固定题型 根据说明给出实体名称 为了方便画图实体可能会多次出现。 若出现多次推荐优先从数据流少的实体进行确定根据说明给出数据存储名称补充缺失的数据流 一般情况下数据流条数若不给定分值/2~分值 数据流之间的顺序无要求 数据流名称尽量不要完全一样后面出现的可以增加限定词例如“通知”“作业已批改的通知” 父图子图平衡加工至少有一个输入数据流和一个输出数据流数据守恒从说明找对应数据流
16上 解析“根据临时预定或变更预定的设备和设施需求分配所需的设备均能满足用户要求和设施更新相应的表”特意提及了设备能满足要求可能是在暗示设备设施是分开表示的结合0层数据流图发现临时预定和变更预定传过来的也是“设备和设施需求”则D3和D4是设施表和设备表答案
16下
官方答案如下说明数据流并非要求名称不能一致
17下 tips五分有六条数据流说明条数和分数木啥太大关系~
随机题型
11上 E1和E3之间不可以有数据流 因为数据流的起点和终点中必须有一个是加工处理
14上 图1-2中处理3只有输出数据流没有输入数据流。D2和D3是黑洞只有输入的数据流没有输出的数据流。是黑洞且与说明中缺少输出数据流才是所谓的问题不要忽略后续的限定条件。因为数据存储没有要求必须有输入且有输出题目中的是对应于说明缺少父图和子图不平衡图1-2中没有图1-1中的数据流“维修情况”。
15上 解析 “功能6发送通知 包含 创建通知 并 发送给学生或老师”“分解加工6 ”则考虑分解为 创建通知 和 发送给学生或老师 进一步简述后一个加工可以简化为发送通知答案
15下 解析 答案 把Email系统作为实体并把通知的终点全部改为Email系统
16上 答案 在图1-1和1-2中增加外部实体Email系统并把素有发给客户的“确认消息”的数据流的终点改为Email系统
16下 在图1-1中增设外部实体“证券交易中心”增加一条数据流“交易信息”起点为“证券交易平台”终点为“证券交易中心” 在图1-2中增设外部实体“证券交易中心”增加从加工“证券交易在线”到此外部实体的数据流“交易信息”增加从加工“证券交易电话”到此外部实体的数据流“交易信息”
17上 答案 父图中加工的输入输出数据流必须和子图中的输入输出数据流在数量上和名字上相同 父图中的一个输入输出数据流对应子图中几个输入输出数据流而子图中组成这些数据流的数据项全体正好是父图中的这一条数据流。
17下 18上 or 父图中加工的输入输出数据流必须和子图中的输入输出数据流在数量上和名字上相同父图中的一个输入输出数据流对应子图中几个输入输出数据流而子图中组成这些数据流的数据项全体正好是父图中的这一条数据流。
18下 19上 解析 答案 二、数据库设计
基础知识 实体 弱实体 子实体 属性 属性是实体某方面的特性。例如学生实体具有学号、姓名、年龄和入学时间等属性。每个属性都有其取值范围例如学号为001~999的六位整型数姓名为十位的字符串年龄的取值范围为18-60等。在同一实体集中每个实体的属性及其域是相同的但可能取不同的值。 简单属性和复合属性 简单属性原子的、不可再分的复合属性可以进一步再分即划分为别的属性 有时用户希望访问某个属性有时希望访问属性的某个成分那么在模式设计时可采用复合属性。例如职工实体集的通信地址可以进一步分为右边、省、市、街道。 若不特别声明通常指的是简单属性 单值属性和多值属性 单值属性定义的属性对于一个特定的实体都只有单独的一个值。例如对于一个特定的学生只对应一个学号、姓名多值属性一个属性对应一组值。例如职工可能有0个、1个或多个亲属则职工的亲属的姓名可能有多个数目 NULL属性 当实体在某个属性上没有值或属性值未知时使用NULL值表示无意义或不知道派生属性 派生属性可以从其他属性得来。例如职工实体集中有“参加工作时间”和“工作年限”属性则“工作年限”的值可以由当前时间和参加工作时间得到故“工作年限”就是一个派生属性 联系 在E-R模型中联系用菱形表示通常菱形框内写明联系名并用无向边分别与有关实体连接起来同时在无向边旁标注上联系的类型11、1n或mn。实体的联系分为实体内部的联系和实体与实体之间的联系。实体内部的联系反映数据在同一记录内部各字段间的联系。 两个不同实体之间的联系 两个不同实体集之间存在以下三种联系类型 一对一11 指实体集E1中的一个实体最多只与实体集E2中的一个实体相联系 eg电影院里一个座位只能做一个观众则观众和座位之间是11的联系一对多1n 表示实体集E1中的一个实体可与实体集E2中的多个实体相联系 eg部门和职工实体集若一个职工只能属于一个部门则这两个实体集之间应是一个1n的联系多对多mn 表示实体集E1中的多个实体可与实体集E2中的多个实体相联系 eg工程项目和职工实体集若一个职工可以参加多个项目一个项目可以有多个职工参加则这两个实体集之间应是一个mn的联系。 两个以上不同实体集之间的联系 两个以上不同实体集之间存在111、11n、1mn和rmn的联系。 eg供应商Supp、项目Proj和零件Part之间多对多对多rmn的联系。表示供应商为多个项目供应多种零件每个项目可用多个供应商供应的零件每种零件可由不同的供应商供应的语义。 病房、病人和医生之间一对多对多1nm的联系。表示一个特护病房有多个病人和多个医生一个医生只负责一个病房一个病人只属于一个病房的语义。 关系模式对关系的描述称为关系模式由关系名和其属性集合构成关系模式的格式为 关系名属性名1属性名2……属性名n 候选码或候选键属性或属性组合其值能够唯一地标识一个元组 主码或主键在一个关系中可能有多个候选码从中选择一个作为主码 外码或外键若一个关系中的属性或属性组并非该关系的码但它们是另外一个关系的码则称其为该关系的外码 E-R图向关系模式转换的规则 一个实体型转换为一个关系模式实体的名称就是关系模式的名称实体的属性就是关系的属性实体的码关键字就是关系的码 一个11联系可以转换为一个独立的关系模式也可以和任意一端对应的关系模式合并 若转化为一个独立的模式则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性每个实体的码均是该关系的候选码。 eg 部门部门号部门名地址 主任姓名性别年龄 领导部门号姓名//当然姓名也是候选码若与某一端实体对应的关系模式合并则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性 eg: 部门部门号部门名地址姓名 主任姓名性别年龄 或者 部门部门号部门名地址 主任姓名性别年龄部门号 一个1n联系可以转换为一个独立的关系模式也可以和任意n端对应的关系模式合并 若转换为一个独立的模式则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性而关系的码为n端实体的码 eg 部门部门号部门名地址 职工姓名性别年龄 所属姓名部门号//主码只能是姓名若和n端实体对应的关系模式合并则需要在该关系模式的属性中加入1端关系模式的码和联系本身的码 eg: 部门部门号部门名地址 职工姓名性别年龄部门号 一个mn联系转换为一个独立的关系模式和该联系相连的各实体的码以及联系本身的属性均转换为关系的属性而关系的码为各实体码的组合 eg: 维修人员职工号姓名部门 设备设备号设备名日期 维修职工号设备号//职工号设备号分别也是维修的外键 三个以上实体间的一个多元联系可以转换为一个独立的关系模式和该联系相连的各实体的码以及联系本身的属性均转换为关系的属性而关系的码为各实体码的组合 超类和子类的转换超类、子类实体都可以转换为一个关系并把超类实体的主码加到子类实体中。 下面E-R图中职员实体是飞行员、机械师和管理员实体的超类超类和子类之间具有继承关系其中各实体的属性为 职员职工号姓名性别年龄参加工作时间 飞行员飞行小时健康检查飞机型号 机械师学历级别专业职称 管理员职务职称 该E-R图转换为如下关系模式 职员职工号姓名性别年龄参加工作时间 飞行员职工号飞行小时健康检查飞机型号 机械师职工号职务职称
固定题型 根据说明补充联系。注意联系名不能重名根据E-R图补充关系模式中的缺失属性给出某几个关系的主键和外键。注意一个空代表着一个或多个属性
13下1nm 14上 解析 本题中的联系很隐晦~靠自己根据实体间的关系以及分数较高猜测出家电和家电厂商的一对多联系。而客服、家电、客户间的多对多关系借助已有的图位置暗示。 答案
14下 解析 答案
16上聚合 解析 答案
19上完整性约束 解析 完整性约束 实体完整性主键参照完整性外键 方法①直接在增加的属性下面画上下划线主键或虚线外键方法②把空缺所在的关系模式中的主键和外键全部列出来一遍 答案
19下“说明”联系及其类型 答案
随机题型
09下弱实体 答案
11下 解析 答案
13下 14上 解析 本E-R图中的员工是电子商务公司的所以电子商务公司的客户经理是该员工的子类而基金公司的基金经理是个新实体答案
14下迷惑题可忽略 解析 答案
15下命名冲突 16上 解析 答案
16下传递依赖 解析 答案
17上 解析 答案
17下全码 18上 19上增加属性选择合适的补充位置 解析 答案
19下传递依赖 答案
20下关系模式问题解决 略 a经理号电话 b地址分公司编号主管号其中主管号是由业务部和主管间的一对一联系并入后增加 c所属业务部编号 分公司关系模式中主键分公司编号外键经理号 业务部关系模式中主键业务部编号外键分公司编号主管号 存在数据冗余修改异常插入异常删除异常等问题 应该把职员关系模式分解为 职员1(职员号姓名岗位所属业务部编号电话) 职员2职员号 家庭成员姓名成员关系
三、UML
基础知识 UML中有四种关系:依赖、关联、泛化、实现 依赖Dependency 依赖是两个事物间的语义关系其中一个事物独立事物发生变化会影响另一个事物依赖事物的语义。 关联Association 关联是一种结构关系它描述了一组链链是对象之间的链接 在关联上可以标注重复度multiplicity又称多重度和角色role。其中重复度的理解类似于联系的类型 聚集Aggregation 聚集是一种特殊类型的关联它描述了整体和部分间的结构关系。 聚合 部分和整体的生命周期不一致即部分可以脱离整体存在。例如班级和组成的同学一个班级是一个整体其中的同学是部分但同学脱离了班级也可以存在。 组合 部分和整体的生命周期一致部分不可以脱离整体。例如人和组成的细胞人是一个整体其中的细胞是部分但是脱离了人细胞也就不能存在了。 泛化(Generalization) 泛化是一种特殊/一般关系特殊元素子元素的对象可替代一般元素父元素的对象 实现Realization 实现是类元之间的语义关系其中一个类元指定了由另一个类元保证执行的契约。在这种情况下会使用实现关系一种是在接口和实现它们的类或构件之间另一种是在用例和实现它们的协作之间。 图Diagram是一组元素的图形表示大多数情况下把图画成顶点代表事物和弧代表关系的连通图。为了对系统进行可视化可以从不同的角度画图这样图是对系统的投影 UML2.0提供了13种图分别是类图、对象图、用例图、序列图、通信图、状态图、活动图、构件图、组合结构图、部署图、包图、交互概览图和计时图。序列图、通信图、交互概览图和计时图都被称为交互图。 类图Class Diagram展现了一组对象、接口、协作和它们之间的关系。在面向对象系统的建模中所建立的最常见的图就是类图。类图给出系统的静态设计视图。包含主动类的类图给出了系统的静态进程视图。 用例图 用例图use case diagram展现了一组用例、参与者Actor以及它们之间的关系 包含关系 扩展关系 用例和用例之间的关系 一个用例执行时可能会发生一些特殊或可选的情况这种情况就是这个用例的扩展用例。 泛化关系 参与者和参与者以及用例和用例之间的关系
固定题型
本道题型中出题方式顺序相对自由不再区分真题中的固定与随机题型
根据说明补充用例图根据说明补充类图
21下用例之间的关系 U1编写迷宫文件U2导入迷宫文件U3设置计时器U1、U2和建立迷宫是泛化关系建立迷宫用例泛化U1、U2用例 U3和操作机器人是包含关系操作机器人用例包含U3用例 用例和用例之间的关系有包含include扩展extend泛化generalizeC1Robos C2TimerPacMan C4:Ghost C5:Sersor C6:FrontSensor C7:ProxiSensor C8:Maze
21上用例之间的关系
做这道题的内心OS《曾经我也想过一了百了》
A1患者 A2:快递人员 A3药师 U1确认处方 观察用例图中功能除了“确认处方”都有对应用例且也是患者有关的 U2:支付 U3微信支付 U4支付宝支付 类图中C1和C2,C3之间是泛化关系找到说明中的有两个泛化的情况 ①取药方式自行到店取药 or 送药上门。 其中送药上门已经有对应用例排除或者降低选择优先级 ②支付方式微信 or 支付宝 虽然形式隐蔽没有出题人暗示的意思但是软考题出得是挺随意的不必担心。没有重复出现为最优选择 C1支付方式 C2:微信支付 C3支付宝支付 C4处方 C5药品 首先C1有两个不同特例考虑支付或者取药方式。 题干中“支付成功之后处方被发送给药师进行药品配制”则当选择支付后支付和处方有关联考虑C4作为处方后续与药师关联与描述对应 关于C5和C4是单向关联考虑快递人员或者药品因为是单向的药品更加合适有什么处方会影响用什么药品但是有什么药品和处方关系不大主要看病症快递人员没必要强调是单向的 包含include:一个用例包含另一个用例当基本用例执行时被包含用例一定会执行。包含关系由基本用例指向被包含用例关系是一条带箭头的虚线虚线上包含 include 扩展extend:当一个用例执行时可能会出现特殊情况和可选情况这时会执行扩展用例。扩展关系由扩展用例指向基本用例关系是一条带箭头的虚线虚线上包含 extend 泛化generalize:父用例泛化子用例子用例继承父用例的所有属性和行为且父用例可以出现的地方子用例都可以将其替换。
20下主要属性 (类图错误C4属于一般应该指向C4)
1 A1房产经纪 A2:系统管理员 U1审批授权 U2修改房产信息 U3删除房产信息 2(a) include (b) extend “定期把售出和停售的房产信息进行归档若确定不再销售某套房产时才删除房产信息”则U3删除房产信息属于特殊情况停售则属于扩展扩展用例指向一般用例 想要U2修改房产信息需要先导出房产信息来获得房产信息属于包括基本用例指向被包含用例 C1:Property C2:House C3:Cando C4:user C5:Manager C6:Agent 首先C1和C4具有子类则在用户和房产中考虑 C5和C1有单向关联则是人对房产进行操作而管理房产信息的人员对房产透明则C1是房产C2,C3是住宅和公寓。 系统会记录房产经纪对房产负责的起止时间且C6和房产间有AgentList,则房产经纪更可能是C6,从而C5是系统管理员 房产经纪负责每套房产的起始时间和终止时间 根据AgentList的英文意思经纪人信息会找房产经纪相关的信息为了稳妥起见可以把房产经济的基本信息和指出要记录的房产经济负责的每套房产的起止时间都加上。本题中把基本信息忽略的原因是问的是“主要” 19下必要属性 A1Receptionist A 2:DentalStaff A3:OfficeStaff U1:Maintain patient info U2:Record office visit info U3:Print invoices 对于U1和U2的顺序官方答案是反过来的解析并没有表现出U1,U2不同的原因没有将其区分。 C1PatientInvoice C2:InsuranceInvoice C3:Invoice C4:Produre C5:OfficeVisit 首先从上面做过的真题可知图中的箭头不能深究讲究个会意即可。所以类图中两个疑似泛化的箭头可以理解为出题老师版本的泛化。则C3考虑为发票C1和病人有关则为给病人的发票从而C2为给医保机构的发票。 剩下的可能类有接待员、办公人员就诊信息治疗。其中C5和病人有一对多的关系C4和医护人员有多对多的关系以及C4和C3有多对多的关系。不是很明显看下面的题目是否有辅助信息。给出C4,C5Patient和DentalStaff的属性会找图中的病人和医护人员的包含属性都已经给出看有哪些其他给出属性的类。刚好有治疗和就诊信息考虑这两个作为C4,C5。“病人在就诊时可能需要接受多项治疗每项治疗由多位医护人员为其服务”。病人和就诊有关医护人员和治疗有关且一次就诊对应一个病人一个病人可以多次前来就诊满足一对多故C5为就诊信息。C4为治疗一次就诊接受多次治疗每次治疗由多位医护人员服务满足多对多。 C4:治疗项目名称、治疗项目描述、治疗的牙齿和费用 C5就诊时间、就诊费用、支付代码、病人支付费用、医保支付费用 Patient:病人姓名、身份证号、出生日期、性别、首次就诊时间和最后一次就诊时间 DentalStaff:姓名、职位、身份证号、家庭住址和联系电话
19上用例描述需包含基本数据流和备选数据流 A1:Buyer A2:Warehouseman A3:Dispathcer U1:Register detail U2:Print order U3:Buy books 基本事件流顾客登录系统浏览书籍信息选择所需购买的书籍以购买数量进入验证界面输入注册码生成订单 备选事件流 1某种书籍的库存量为0则顾客无法查询到该书籍信息 2书籍的购买数量超过库存量提示库存不足 3注册码不正确提示验证码错误 4顾客需要打印订单 C1Customer C2:Order C3:Books 先从有属性的进行判断确定C1,C3 然后剩余的给出英语名称的只有Order,代入C2可行再确定C2 18下 C1SNSGroup C2:SNSUser C3:SNSAdmin观察者模式 意图定义对象间的一种一对多的依赖关系当一个对象的状态发生改变时所有依赖于它的对象都得到通知并被自动更新 适用场合当对一个对象的改变需要同时改变其他对象而不知道具体有多少对象有待改变时当一个对象必须通知其他对象而它又不能假定其他对象是谁即不希望这些对象是紧耦合的略
18上 A1:Driver A2:Central system A3:Regional center A4:Traffic advice centerU1:Underpaid transaction U2:Record Illegal use U3:Create transaction U4:Record traffic event U5:Charge card 从用例图中的两个扩展关系为切入点根据用例列表可能的情况有 基本用例记录交易 扩展用例1记录透支信息扩展用例2记录失败信息作为特殊情况。 和交易记录有关的是驾驶员一定中心系统区域系统不能确定继续找信息 U4只和A3,A4有关磁卡充值和驾驶员有关排除则U4是记录交通信息。说明中和交通信息有关的只有区域系统和电台则这两者为A3,A4 从而A1,A2为驾驶员和中心系统 U5只剩磁卡充值和驾驶员和中心系统有关符合说明 C1Central C2:Toll gantry C3:Traffic lanes C4:Radar sensor C5:Radio transceiver C6:Digital Camera 有三个组成部分则C3是车道从而C4,C5,C6分别是雷达、无线、相机C2是龙门架 C1和区域系统有关联则考虑驾驶员和中心系统两个都是系统更协调则C1为中心系统 17上类的分类 四、算法
基础
回溯
N皇后问题
题型
代码填空时空复杂度/算法策略
五、设计模式 简单工厂模式
属于创建型模式但不属于23种设计模式之一。
定义定义一个工厂类他可以根据参数的不同返回不同类的实例被创建的实例通常都具有共同的父类。在简单工厂模式种用于被创建实例的方法通常称为静态static方法故简单工厂模式又称为静态工厂方法Static Factory Method需要什么产品就传入产品对应的参数就可以获取所需要的产品对象而无需知道其 实现过程eg:有一家饺子店当客户需要某种饺子时饺子店生成对应的饺子给客户可以把饺子店视为工厂Factory,饺子视为产品Product饺子的名称视为参数饺子店根据不同的参数返回不同的饺子。比如客户想要荠菜饺子此处的荠菜就是参数饺子店会根据参数荠菜返回荠菜饺子(在饺子店有荠菜饺子的前提下)三类角色 工厂核心负责实现创建所有产品的内部逻辑 工厂类可以被外界直接调用创建所需对象抽象产品工厂类所创建的所有对象的父类 封装了产品对象的公共方法所有的具体产品为其子类对象具体产品简单工厂模式的创建目标 所有被创建的对象都是某个具体类的实例。它要实现抽象产品中声明的抽象方法。 public class SimpleFactory {public static void main(String[] args){Product productA Factory.createProduct(A);productA.info();Product productB Factory.createProduct(B);productB.info();}
}class Factory{public static Product createProduct(String type){Product product null;switch(type){case A:product new ProductA();break;case B:product new ProductB();break;default:System.out.println(no type type product);}return product;}
}abstract class Product{public abstract void info();
}class ProductA extends Product{Overridepublic void info(){System.out.println(Product A);}
}class ProductB extends Product{Overridepublic void info() {System.out.println(Product B);}
}工厂方法模式
意图定义一个用于创建对象的接口让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类 结构 其中Product定义工厂方法所创建的对象的接口 ConcreteProduct实现Product接口 Creator声明工厂方法该方法返回一个Product类型的对象。Creator也可以定义一个工厂方法的默认实现它返回一个默认的ConcreteProduct对象可以调用工厂方法以创建一个Product对象 ConcreteCreator重定义工厂方法以返回一个ConcreteProduct实例适用性 Factory模式适用于 当一个类不知道它所必须创建的对象的类时当一个类希望由它的子类来指定它所创建对象时当类把创建对象的职责委托给多个帮助子类中的某一个并且希望把哪一个帮助子类是代理者这一信息局部化时
public class FactoryP{public static void main(String[] args) {IFactory factoryA new FactoryA();IProduct productA factoryA.createProduct();productA.info();IFactory factoryB new FactoryB();IProduct productB factoryB.createProduct();productB.info();}
}interface IFactory{public IProduct createProduct();//接口中的元素是public abstract的可以省略
}interface IProduct{public void info();
}class FactoryA implements IFactory{Overridepublic IProduct createProduct() {return new ProductA1();}
}class FactoryB implements IFactory{Overridepublic IProduct createProduct(){return new ProductB1();}
}
class ProductA1 implements IProduct{Overridepublic void info() {System.out.println(Product A1);}
}class ProductB1 implements IProduct{Overridepublic void info(){System.out.println(Product B1);}
}抽象工厂模式
意图特点提供一个创建一系列相关或相互依赖对象的接口而无须指定它们具体的类结构 其中AbstractFactory声明一个创建抽象产品对象的操作接口 ConcreteFactory实现创建具体产品对象的操作 AbstractProduct是一类产品对象声明一个接口 ConcreteProduct定义一个将被相应的具体工厂创建的产品对象实现AbstractProduct接口 Client仅使用由AbstractFactory和AbstractProduct类声明的接口适用性 Abstract Factory模式适用于 一个系统要独立于它的产品的创建、组合和表示时一个系统要由多个产品系列中的一个来配置时当要强调一系列相关的产品对象的设计以便进行联合使用时当提供一个产品类库只想显示它们的接口而非实现时
public class AbstractFactory {public static void main(String[] args) {Factory factory1 new Fractory1();ProductA productA factory1.createProductA();productA.info();Factory factory2 new Factory2();ProductB productB factory2.createProductB();productB.info();}
}interface Factory{public ProductA createProductA();public ProductB createProductB();
}class Fractory1 implements Factory{Overridepublic ProductA createProductA() {return new ProductA1();}Overridepublic ProductB createProductB() {return new ProductB1();}
}class Factory2 implements Factory{Overridepublic ProductA createProductA() {return new ProductA2();}Overridepublic ProductB createProductB() {return new ProductB2();}
}interface ProductA{public void info();
}interface ProductB{public void info();
}class ProductA1 implements ProductA{Overridepublic void info() {System.out.println(Product A1);}
}class ProductA2 implements ProductA{Overridepublic void info() {System.out.println(Product A2);}
}class ProductB1 implements ProductB{Overridepublic void info() {System.out.println(Product B1);}
}class ProductB2 implements ProductB{Overridepublic void info() {System.out.println(Product B2);}
}生成器模式Builder
意图把一个复杂对象的构建和它的表示分离使得同样的构建过程可以构建不同的表示结构 其中Builder为创建一个Product对象的各个部件指定抽象接口 ConcreteBuilder实现Builder的接口以构造和装配该产品的各个部件定义并明确它所创建的表示提供一个检索产品的接口 Director构造一个使用Builder接口的对象 Product表示被构造的复杂对象。ConcreteBUilder创建该产品的内部表示并定义它的装配过程。包含定义组成组件的类包括把这些组件装配成最终产品的接口适用性 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时当构造过程必须允许被构造的对象有不同的表示时
原型模式Prototype
意图用原型实例指定创建对象的种类并通过复制这些原型创建新的对象结构 Prototype声明一个复制自身的接口 ConcretePrototype实现一个复制自身的操作 Client让一个原型复制自身从而创建一个新的对象适用性 当一个系统应该独立于它的产品创建、构成和表示时当要实例化的类在运行时指定时例如通过动态装载为了避免创建一个与产品类层次平行的工厂类层次时当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些
适配器模式Adapter
意图把一个类的接口转换为客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作结构 类适配器使用多重继承对一个接口和另一个接口进行匹配。对象适配器依赖于对象组合。其中 Target定义Client使用的和特定领域相关的接口 Client和符合Target接口的对象协同 Adaptee定义一个已经存在的接口这个接口需要适配 Adapter对Adaptee的接口和Target接口进行适配 适用性 想使用一个已经存在的类而它的接口不符合要求想创建一个可以复用的类该类可以和其他不相关的类或不可预见的类即那些接口可能不一定兼容的类协同工作仅适用于对象Adapter想使用一个已经存在的子类但是不可能对每一个都进行子类化以匹配它们的接口。对象适配器可以适配它的父类接口
桥接模式Bridge
意图把抽象部分和其实现部分分离使它们都可以独立地变化结构 其中Abstraction定义抽象类的接口维护一个指向Implementor类型对象的指针 RefinedAbstraction扩充由Abstraction定义的接口 Implementor定义实现类的接口该接口不一定要与Abstraction的接口完全一致事实上这两个接口可以完全不同。一般来说Implementor接口仅提供基本操作而Abstraction定义了基于这些基本操作的较高层次的操作 ConcreteImplementor实现Implementor接口并定义它的具体实现适用性 不希望在抽象和它的实现部分之间有一个固定的绑定关系。例如这种情况可能是因为在程序运行时刻实现部分应可以被选择或者切换类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。这是Bridge模式使得开发者可以对不同的抽象接口和实现部分进行组合并分别对它们进行扩充对一个抽象的实现部分的修改应对客户不产生影响即客户代码不必重新编译C想对客户完全隐藏抽象的实现部分有许多类要生成的类层次结构想在多个对象间共享实现可能使用引用计数但同时要求客户并不知道这一点
组合模式Composite
意图把对象组合成树型结构以表示“整体-部分”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性结构 Component为组合中的对象声明接口在适当情况下实现所有类共有接口的默认行为声明一个接口用于访问和管理Component的子组件可选在递归结构中定义一个接口用于访问一个父组件并在合适的情况下实现它。 Leaf在组合中表示叶节点对象叶节点没有子节点在组合中定义图元对象的行为 Composite定义有子组件的那些组件的行为存储子组件在Component接口中实现和子组件有关的操作 Client通过Component接口操纵组合组件的对象 适用性 想表示对象的部分-整体层次结构希望用户忽略组合对象和单个对象的不同用户将统一地使用组合结构中的所有对象
装饰器模式Decorator
意图动态地给一个对象添加一些额外的职责。就增加功能而言Decorator模式比生成子类更加灵活结构 Component定义一个对象接口可以给这些对象动态地添加职责 ConcreteComponent定义一个对象可以给这个对象添加一些职责 Decorator维持一个指向Component对象的指针并定义一个与Component接口一致的接口 ConcreteDecorator向组件添加职责适用性 在不影响其他对象的情况下以动态、透明的方式给单个对象添加职责处理那些可以撤销的职责当不能采用生成子类的方式进行扩充时。一种情况是可能有大量独立的扩展为支持每一种组合将产生大量的子类使得子类数目呈爆炸性增长。另一种情况可能是由于类定义被隐藏或类定义不能用于生成子类
16下 享元模式Flyweight
意图运用共享技术有效地支持大量细粒度的对象结构 Flyweight描述一个接口通过这个接口Flyweight可以接受并作用于外部状态 ConcreteFlyweight实现Flyweight接口并为内部状态如果有增加存储空间 ConcreteFlyweight对象必须是可共享的。它所存储的状态必须是内部的即它必须独立于ConcreteFlyweight对象的场景 并非所有的Flyweight子类都需要被共享。Flyweight接口使共享成为可能但它并不强制共享。在Flyweight对象结构的某些层次UnsharedConcreteweight对象通常把ConcreteFlyweight对象作为子节点 FlyweightFactory创建并管理Flyweight对象确保合理地共享Flyweight当用户请求一个Flyweight时FlyweightFactory对象提供一个已创建的实例或者不存在时创建一个实例 Client维持一个对Flyweight的引用计算或存储一个或多个Flyweiht的外部状态适用性 一个应用程序使用了大量的对象完全由于使用大量的对象造成很大的存储开销对象的大多数状态都可变为外部状态如果删除对象的外部状态则可以用相对较少的共享对象取代很多组对象应用程序不依赖于对象标识。由于Flyweight对象可以被共享则对于概念上明显有别的对象标识测试将返回真值
命令模式Command
意图把一个请求封装为一个对象从而使得可以用不同的请求对客户进行参数化对请求排队或记录请求日志以及支持可撤销的操作结构 Command声明执行操作的接口 ConcreteCommand把一个接收者对象绑定于一个动作调用接收者相应的操作以实现Execute Client创建一个具体命令对象并设定它的接收者 Invoker要求该命令执行这个请求 Receiver知道如何实施和执行一个请求相关的操作。任何类都可能作为一个接收者适用性 抽象出待执行的动作以参数化某对象。在不同的时刻指定、排列和执行请求支持取消操作支持修改日志用构建在原语操作上的高层操作构造一个系统
14下 解析 答案
观察者模式Observer
意图定义对象间的一种一对多的依赖关系当一个对象的状态发生改变时所有依赖于它的对象都得到通知并被自动更新结构
Subject(目标)知道它的观察者可以有任意多个观察者观察同一个目标提供注册和删除观察者对象的接口 Observer观察者为那些在目标发生改变时需获得通知的对象定义一个更新接口 ConcreteSubject(具体目标)把有关状态存入各ConcreteOberver对象当它的状态发生改变时向它的各个观察者发出通知 ConcreteObserver(具体观察者)维护一个指向ConcreteSubject对象的引用存储有关状态这些状态应与目标的状态保持一致实现Observer的更新接口以使自身状态和目标的状态保持一致
适用性 当一个抽象模型有两个方面其中一个方面依赖于另一个方面把这两者封装在独立的对象中以使它们可以各自独立地改变和复用当对一个对象的改变需要同时改变其他对象而不知道具体有多少对象有待改变时当一个对象必须通知其他对象而它又不能假定其他对象是谁即不希望这些对象是紧耦合的
14上 解析 答案
状态模式 意图允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类 结构 Context上下文定义客户感兴趣的接口维护一个ConcreteState子类的实例这个实例定义当前状态 State状态定义一个接口以封装与Context的一个特定状态相关的行为 ConcreteState具体状态子类每个子类实现和Context的一个状态相关的行为 适用性 一个对象的行为决定它的状态且它必须在运行时刻根据状态改变它的行为一个操作中含有庞大的多分支的条件语句且这些分支依赖于该对象的状态。这个状态常用一个或多个枚举常量表示。通常有多个操作包含这一相同的条件结构。State模式把每一个条件分支放入一个独立的类中。这使得开发者可以根据对象自身的情况把对象的状态作为一个对象这一对象可以不依赖于其他对象独立变化
11下 解析 答案 18下 策略模式
意图定义一系列算法把它们一个个封装起来且使它们可以相互替换。此模式使得算法可以独立于使用它们的客户而变化结构 Strategy(策略)定义所有支持的算法的公共接口。Context使用这个接口来调用某ConcreteStrategy定义的算法 ConcreteStrategy(具体策略)以Strategy接口实现某具体算法 Context(上下文)用一个ConcreteStrategy对象来配置维护一个对Strategy对象的引用可定义一个接口来让Strategy访问它的数据适用性 许多相关的类仅仅是行为不同需要使用一个算法的不同变体算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构一个类定义了多种行为且这些行为在这个类的操作中以多个条件语句的形式出现把相关的条件分支移入它们各自的Strategy类中以代替这些条件语句
10上 访问者模式Visitor 意图表示一个作用于某对象结构中的各元素的操作。它允许在不改变各元素的类的前提下定义作用于这些元素的新操作 结构 Visitor(访问者)为该对象结构中ConcreteElement的每一个类声明一个Visit操作。该操作的名字和特征标识了发送Visit请求给该访问者的那个类这使得访问者可以确定正被访问元素的具体的类。这样访问者就可以通过该元素的特定接口直接访问它。 ConcreteVisitor(具体访问者)实现每个有Visitor声明的操作每个操作实现本算法的一部分而该算法片段乃是对应于结构中对象的类。ConcreteVisitor为该算法提供了上下文并存储它的局部状态。这一状态常常在遍历该结构的过程中累计结果 Element元素定义以一个访问者为参数的Accept操作。 ConcreteElement(具体元素)实现以一个访问者为参数的Accept操作。 ObjectStructure(对象结构)能枚举它的元素可以提供一个高层的接口以允许该访问者它的元素可以是一个组合或一个集合如一个列表或一个无序集合 适用性 一个对象结构包含很多类对象它们有不同的接口而用户想对这些对象实施一些依赖于其具体类的操作需要对一个对象结构中的对象进行很多不同的并且不相关的操作而又想要避免这些操作“污染”这些对象的类。Visitor使得用户可以把相关的操作集中起来定义在一个类中。当该对象结构被很多应用共享时用Visitor模式让每个应用仅包含需要用到的操作定义对象结构的类很少改变但经常需要在此结构上定义新的操作。
15上 中介者模式Mediator 意图用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显示地相互引用从而使其耦合松散且可以独立地改变它们之间的交互。 结构 Mediator(中介者)定义一个接口用于各同事Colleague对象通信 ConcreteMediator(具体中介者)通过协调各同事对象实现协作行为了解并维护它的各个同事 Colleague class(同事类)知道它的中介者对象每一个同事类对象在需要和其他同事通信的时候和它的中介者通信 适用性 一组对象以定义良好但是复杂的方式进行通信产生的相互依赖关系结构混乱且难以理解一个对象引用其他很多对象并且直接与这些对象通信导致难以复用该对象想定制一个分布在多个类中的行为而又不想生成太多的子类
20下
