《第七讲对象设计.ppt》由会员分享，可在线阅读，更多相关《第七讲对象设计.ppt（50页珍藏版）》请在三一文库上搜索。
1、第七讲 对象设计,饰犹匿扭免琼桩预踞檬粮蓬驯治钠秘敲营离蝉挥等浚朗范硼呜秩枝壤违农第七讲对象设计第七讲对象设计,目标,学习使用面向对象设计的5个GRASP原则或模式,服岗红茸少遏传另窝换肄玄劳盗朵刀哎概须放鳃副璃硷褥聘胃赣返冯屎厉第七讲对象设计第七讲对象设计,OOD,决定方法归属于哪个对象和对象之间如何交互，其意义重大，应谨慎从事。 掌握OOD可以通过在实例中学习和在设计中对模式的命名 建模的目的是为理解和沟通而不是构建文档 OOD的解释：首先明确你的需求并创建领域模型，然后为适当的类添加方法，再定义对象之间的消息以实现需求,蛮姚应包仅索萝屏督兔刁麻厌纲扰炭呕滔犯照匈择萍秤神陕牛巫陋勾移均第七
2、讲对象设计第七讲对象设计,职责和职责驱动设计,UML把职责定义为“类的契约或义务”。就对象的角色而言，职责与对象的义务和行为相关。职责分为以下两种类型：行为和认知 对象的行为职责包括： 自身执行一些行为，如创建对象或计算 初始化其他对象中的动作 控制和协调其他对象中的活动 对象的认知职责包括： 对私有封装数据的认知 对相关对象的认知 对其能够导出或计算的事物的认知,妨颈渊调颈圃众酚沁昼温涎漠蔼板唐过实憎日蹄茁碌锐葬炔鳞奉岂赎播榆第七讲对象设计第七讲对象设计,准则,对于软件领域对象来说，由于领域模型描述了领域对象的属性和关联，因此其通常产生与“认知”相关的职责。例如，如果领域模型的Sale类具有
3、time属性，那么根据低表示差异的目标，软件的Sale类自然也应该知道其产生的时间 职责的粒度会影响到类和方法的转换。例,“提供访问关系数据库”，“创建Sale” 职责与方法并非同一事物，职责是一种抽象，而方法实现了职责,掳箭拯揉财饱厩不陌防囱众巷失猴棉忻约攒曾锄单骗炉心乎艺您糕帆荚赖第七讲对象设计第七讲对象设计,GRASP原则或模式是一种学习工具，它能帮助你理解基本对象设计，并且以一种系统的、合理的、可以解释的方式来运用设计推理。对这种设计原则进行理解和使用的基础是分配职责的模式 在UML中，绘制交互图是考虑这些职责（实现为方法）的时机 简单地讲，好的模式是成对的问题/解决方案，并且具有广为
4、人知的名称，它能用于新的语境中，同时对新情况下的应用、权衡、实现、变化等给出了建议,优哈蔫眶汉喊况边啃呼瀑泄漾炒蚂纫碰恫蕴圣茁守悸平室晚灰杉屈翟吮了第七讲对象设计第七讲对象设计,模式命名的好处,对模式、设计思想或原则命名具有以下好处： 它支持将概念条理化地组织为我们的理解和记忆 它便于沟通 模式是一种优秀的学习工具，可以用来命名、表示和记忆那些基本和经典的设计思想,叔赏务析掖映盏窒块砒搽埂厚萨吉卷沾罩通旗晤吱墒矫稗鄂上框密隔侯晴第七讲对象设计第七讲对象设计,对象设计技巧与UML表示法技巧,绘制UML反映了对设计作出的决策 对象设计技术并不一定要了解如何绘制UML 基本的对象设计需要了解的是：
5、职责分配原则 设计模式,穴圭慌尉告陡询绢姆赃滞匪学唱疫弃勾怪焚曹语缩江袄号竣憎厦与远监琳第七讲对象设计第七讲对象设计,对象设计,以迭代方法的设计示例 已经完成了哪些活动？以前的活动和制品 事物之间具有什么样的关系？以前的制品对OO设计的影响 需要完成多少设计建模工作，如何完成？ 有哪些输出？ 分析制品与对象设计之间有什么关系？,返败噪撒痘犀匣粹辨盐挥本莉势损嫉楷态磁劳瓮掩掂勤说分漾狠垛甫刀缚第七讲对象设计第七讲对象设计,对象设计的输入是什么,场景 UML包图 补充规格说明 词汇表 领域模型,终瓦渠禽悸晚松跺沪烫淑可姚杖堵接挂守睁贬捎刮固宙畔围蔫蚀芳醒舶名第七讲对象设计第七讲对象设计,对象设计中
6、的活动,给定一个或多个输入，开发者有以下3个选择： 1：立即开发编码（理想的情况是用测试优先开发方式） 2：开发为对象设计进行一些UML建模 3：利用其他建模技术，如CRC cards.,俺票现厦挨熏聂概闯余呛蔽沂擂骋赏不茫雨蛀糖蔡赵碳成礼混炬定祭董合第七讲对象设计第七讲对象设计,对象设计中的活动,在UML案例中，真正要关注的并不是UML，而是可视化建模，即使用一种语言，这种语言比纯文本有更强的可视化功能。 方法是使用基于职责驱动设计，考虑怎样给协作中的对象分配职责,缆驳辣美棍植钢凭瞳凄搓饭枣翼论献嫡沧孟遇乍饶殉呢毗去瀑寇冯歼坚亿第七讲对象设计第七讲对象设计,对象设计的输出,考虑UML交互图和
7、类图 例如： 尤其对于对象设计而言，我们期望在开始编码之前针对设计中的难点创建UML交互图、类图和包图 UI的草图和原型 数据库模型 报表的草图和原型,磁鞭狞逊罐庭鹅龄够煌扮坝啡酷返确浮菏雕痴睹絮依旅咀粒榔敲拘茅钱并第七讲对象设计第七讲对象设计,职责和职责驱动设计,思考软件对象设计以及大型构件的流行方式是，考虑其职责、角色和协作。这些被称为职责驱动设计的大型方法的一部分。 对象职责 其所作所为的抽象,残询讫敲峰嫁宅损郑劫现鸯吏耻傀注检蚜镁心哀厌躇粮雄翟兴刮摔瓦赠撞第七讲对象设计第七讲对象设计,职责,类元的契约或义务 就对象的角色而言，职责与对象的义务和行为相关 职责分为两种类型： 行为： 自身
8、执行一些行为，如创建对象或计算 初始化其他对象中的动作 控制和协调其他对象中的活动 认知： 对私有封装数据的认知 对相关对象的认知 对其能够导出或计算的事物的认知 例如：Sale负责创建SaleLineItems(行为职责) Sale负责认知其总额（认知职责）,图浆毫据跟倾彤掏嘛需疑夫锹适漂搂耻针染治合津已驮己抚刀娇程碰索拨第七讲对象设计第七讲对象设计,职责方法,职责的粒度会影响到类和方法的转换 职责与方法并非同一事物，职责是一种抽象，而方法实现了职责,靡泉给耶依妹忱唉全唇张镇悔水桅侠梁坷虞脚困胳望硅孪蛔翔旦氰胸逛快第七讲对象设计第七讲对象设计,职责协作,RDD也包括了协作的思想 职责借助于方
9、法来实现，该方法既可以单独动作，也可以于其他方法和对象协作,虐枕粥饵捂则翻悼盔撕未胚导铜宴多饲赫叭虚骄笑夜运任附鲍崩然蔬眨担第七讲对象设计第七讲对象设计,职责协作,Sale类可以定义一个或多个来获取其总额，比如命名为getTotal方法。为了完成该职责，Sale可能与其他对象协作，例如每个SaleLineItem对象发送getSubtotal消息以获取其小计金额,嵌逢又见调帐劳恤考牧硼芍绝甄萎呀蛾蜜抄匹饭帆顿寨玛惠撵缅琴历烧庚第七讲对象设计第七讲对象设计,RDD,RDD是思考OO软件设计的一般性隐喻 RDD使我们把OO设计看作是有职责对象进行协作的共同体 GRASP对一些基本的职责分配原则进行
10、了命名和描述，因此掌握这些原则有助于支持RDD,耻痕妆懈烫逗视胯半稽也厦荤蓖疼累背庇浇逗郑豫傻播皋震欢呆仰礁道弄第七讲对象设计第七讲对象设计,GRASP,GRASP是通用职责分配软件模式（General Responsibility Assignment Software Patterns）的缩写 GRASP=使用职责进行OO设计的学习工具 GRASP原则或模式是一种学习工具，它能帮助你理解基本对象设计，并且以一种系统的、合理的、可以解释的方式来运用设计推理 对这种设计原则进行理解和使用的基础是分配职责的模式 目标： 以GRASP作为工具，帮助掌握OOD的基本知识并理解对象设计中的职责分配,痹
11、雇抿菱伞帮烘艇塔害手巾钞巳嘱弟妙皑渍帕父负够色逗飘参镣盖柯盯湾第七讲对象设计第七讲对象设计,职责、 UML 、GRASP,在UML中，绘制交互图是考虑这些职责（实现为方法）的时机 GRASP中的基本原则可以指导分配职责，当绘制UML交互图以及编写代码时，就可以运用GARSP原则了。,幽绞娃勃柳讶晶庆淖光烬啤恳易凡洞奈筐詹垦诽水伞串胸沿危觉欣泊衔怨第七讲对象设计第七讲对象设计,GRASP的模式,GRASP的9个模式如下所示： 创建者（Creator） 控制器（Controller） 纯虚构（Pure Fabrication） 信息专家（Information Expert） 高内聚（High C
12、ohesion） 间接性（Indirection） 低耦合（Low Coupling） 多态性（Polymorphism） 防止变异（Protected Variations）,诬则随依告聂簧灸厘乌阶廖聪必当蹄剖竣锤篓萄浚奈饶粥惜图员非纬嘶福第七讲对象设计第七讲对象设计,GRASP之一创建者,问题: 谁有责任来创建类的实例？,办金甭喊亨宇非舟疫人哭赘拇锈霉可济颁堕桔累膝扩祖镰激淑陕笑硷抛恕第七讲对象设计第七讲对象设计,创建者,名称：创建者（Creator） 问题：谁创建了A？ 解决方案（建议）：如果以下条件之一为真时（越多越好），将创建类A实例的职责分配给类B: B”包含”或组成聚集了A B记
13、录A B直接使用A B具有A的初始化数据，并且在创建A时会将这些数据传递给A 如果有一个以上的选项适用，通常首先聚集或包含A的类B 注意：B和A指的是软件对象，而不是领域模型对象 技巧：依靠LRG（低表示差异），来从领域模型中获得灵感,惶念扛陋浸辫银疑攻孤章握剔营滦愁蛛矽钳砍实锑挑敏孵任骄铲铁存矫深第七讲对象设计第七讲对象设计,创建者,优点：支持低耦合，意味着它具有较低的维护依赖性和较高的复用性。 相关模式或原则： 低耦合 具体工厂和抽象工厂 整体-部分描述了定义聚合对象的模式，它支持对构件的封装,缘效拂学圣虽扫扬丁哉于密晚管草壹囚舷成袒灿屑壤慧春橇篓约捅铰蚀埃第七讲对象设计第七讲对象设计,创
14、建者-讨论,创建者模式指导我们分配那些与创建对象有关的职责。创建者模式的基本意图是寻找在任何情况下都与被创建对象具有连接的创建者。如此选择是为了保持低耦合。 有时，可以通过寻找具有初始化数据的类来确定创建者，这些数据将在创建过程中传递给被创建者,菲佃悸湾慧穆铣芭袍砰惭研治析陈瑞碾炊芬兼篷别普挠儿靴朔粥栖许蕊声第七讲对象设计第七讲对象设计,创建者-禁忌,对象的创建常常具有相当的复杂性，例如为了性能而使用回收的实例，基于某些外部特性值有条件地创建一个或一族类的实例，等等。在这些情况下，最好的方法是把创建职责委派给称为具体工厂（Concrete Factory）或抽象工厂（Abstract Fact
15、ory）的辅助类，而不是使用创建者所建议的类,斑瑶畴贰缄钩漫掌状萎恼痘猩收滔碘斧氧托撩惋王族缸糖雅澄浪脑哆弟豁第七讲对象设计第七讲对象设计,GRASP之二信息专家,名称：信息专家（Information Expert） 问题：给对象分配职责的基本原则是什么？ 解决方案：把职责分配给具有完成该职责所需信息的那个类,稍桌叮释文酷泻互辅揖疏孺四辣诫宫气菏向类兔肉冲煞含隶嘻遏辗孰上谍第七讲对象设计第七讲对象设计,信息专家-示例,Sale time,Sales LineItem quantity,Product Description description price itemID,1,1.*,Con
16、tains,1,*,Described-by,祷掉榜郝什羌钓甥桶源匠截厦脑杠狈管旗晴盖药孔狂廷氢蔡区声赵摧解丹第七讲对象设计第七讲对象设计,信息专家-示例,问题：哪个类应当负责了解销售的总额？ 按照信息专家（Information Expert）的建议，我们应当寻找具有确定总额所需信息的那个对象类。 问题：我们要查看领域模型或设计模型来分析具有所需信息的类？ 答案：如果在设计模型中存在相关的类，首先查看设计模型；否则查看领域模型，并尝试利用（或扩充）它的表示，以激发相应设计类的创建,盗惭攫君昭礁虚各晌中亲式鬃谣芍脖樟沥系淑涧摩桥蛋匠榜洼轮髓逆准侥第七讲对象设计第七讲对象设计,信息专家-示例,:
17、Sale,t=getTotal,新方法,Sale,Time ,getTotal(),炉继奖辞写缎操藤免淌瞥良域饯锁危汰仁尺驯糙币铭末谗夯酋懈汀峭雪挑第七讲对象设计第七讲对象设计,信息专家-示例,:Sale,t=getTotal,新方法,Sale,time ,getTotal(),Lineitemsi SalesLineitem,1*:st=getSubtotal,SalesLineItem,quantity,getSubtotal(),这种表示法指明我们将遍历集合中的所有元素,镰哮赘捻矣窥饿续靖株讼令悸抬趁近盈沉吨措朗捆捏愁忿醋带根帖溶扑托第七讲对象设计第七讲对象设计,信息专家-示例,:Sal
18、e,t=getTotal,Lineitemsi SalesLineitem,1*:st=getSubtotal,Product Description,1.1:p:=getPrice(),Sale,time ,getTotal(),SalesLineItem,quantity,getSubtotal(),新方法,Product Description,description price itemID,getPrice(),菲病型坞挡径衬际呼尤洪饮寨傻痔国迢椰些颁跃柳泣铱时窟平谷农策延厌第七讲对象设计第七讲对象设计,信息专家-示例,设计类,职责,Sale知道销售的总额 SalesLineItem
19、知道商品的小计 ProductDescription知道产品的价格,杖谋牟劝影涅谨利痪脐持壳仕奇绷用苗篆箩型拼锨辖驰拴拘爪悄爆摩若涤第七讲对象设计第七讲对象设计,信息专家-示例,:Register,:Sale,p:Payment,makePayment(),1:create(),2:addPayment(P),函仑展馁猫阁淆让菌铲帜咳第蠢烽亦撤弟严巳情磅唁钎铆宿殉启违量侗厘第七讲对象设计第七讲对象设计,信息专家-示例,:Register,:Payment,:Sale,makePayment(),1:makePayment(),1.1.create(),冈显妖朋很敬疚巧哀靴炒洋矢译泵呵郊嘶榨感软
20、砍衙募垄缉侥伞眺迂垫氧第七讲对象设计第七讲对象设计,信息专家-示例,:Register,:ProcessSaleHandler,enterItem(id,quantity),enterItem(id,quantity),控制器的选择,菌咬辖狞依凉休奔椭剑脖阐舍啤囤矿淄絮乃冒睦埂张阀迂以漓汛阴莲拖懈第七讲对象设计第七讲对象设计,信息专家-示例,:Register,:Payment,mackPayment(),create(),addPayment(p),:Sale,Register 创建Payment,罩壕旬匣潮匿乍肮眯抵物虏售佰澳粒琵材呆规兄露画红野傻痉矛畅纱窗衡第七讲对象设计第七讲对象设计,
21、信息专家-示例,:Register,:Payment,mackPayment(),create(),:Sale,mackPayment(),拖氟拜顿号尾靖砸镜婉蔚始鸣唬工容缄秒战系埃拯陆勿番阴狼找阳篓经痉第七讲对象设计第七讲对象设计,GRASP之三低耦合,问题： 怎样降低依赖性，减少变化带来的影响，提高重用性？ 耦合是对某元素之间的连接、感知和依赖程度的度量。具有低（或弱）耦合的元素不会包括类、子系统、系统等 具有高（或强）耦合的类依赖于许多其他的类，这样的类或许不是我们所需要的。有些类会遇到以下问题： 由于相关类的变化而导致本体的被迫变化 难以单独地理解 由于使用高耦合类时需要它所依赖的类，
22、因此很难重用,苇幼潍钎烈彦横殉飞熏蜂铬邀枝雁殷抒咐啦厂澎卖拼巩补曾环播渣碗狄告第七讲对象设计第七讲对象设计,低耦合,名称：低耦合（Low Coupling） 问题：如何减少因变化产生的影响？ 解决方案： 分配职责以使（不必要的）耦合保持在较低的水平。利用这一原则来评估可选方案,庶舱孟晓介悄嚎杰添渍续侨拾朗良浴清关滇收闽茄枢献色忱袍真巨跃怖匹第七讲对象设计第七讲对象设计,GRASP之四高内聚,问题： 怎样保持对象是有重点的、可理解的、可管理的，并且能够支持低耦合？ 从对象设计的角度上说，内聚（或更为专业地说，是功能内聚）是对元素职责的相关性和集中度的度量。如果元素具有高度相关的职责，而且没有过多
23、工作，那么该元素具有高内聚性。这些元素包括类、子系统等等。,炎嫌磋茫瞪呆建锡匡欣肛曼衔赶下铆居狮臃抿去珐膜考峪辗诺迅错挖毗龟第七讲对象设计第七讲对象设计,高内聚,名称：高内聚（High Cohesion） 问题：怎样使对象保持有内聚、可理解性和可管理性，同时具有支持低耦合的附加作用？ 解决方案： 职责分配应保持高内聚，依此来评估备选方案。 在实践中，内聚程度不能脱离其他职责及其他原则（如专家和低耦合）单独地考虑,拯彭类抄均贪滥络橱邱栏犬饲支抿桔衅涤淖哟鸯迂泥义浸嫩颗锯酒逮蹋上第七讲对象设计第七讲对象设计,GRASP之五控制器,根据MVS原则，我们知道UI对象不应当包含应用逻辑或业务逻辑。因此，
24、一旦UI对象获得了鼠标等事件，它们应该把该请求委派给领域层的领域对象 问题： 在UI 层之上首先接收和协调（控制）系统操作的第一个对象是什么？ 在SSD分析期间，要首先探讨系统操作。这些是我们系统的主要输入事件。例如，当使用POS终端的收银员按下“结束销售”按钮时，他就发起了表示“销售已经终止”的系统事件。类似地，当使用文字处理器的书写者按下“拼写检查”按钮时，他就发起了表示“执行拼写检查”的系统事件 控制器是UI层之上的第一个对象，它负责接收和处理系统操作消息,权峻郭寡迸佰竣桑品拖锯骨彼东卖捻杜浊捡闷巍恰剧剂惟镣化钓寅株维碑第七讲对象设计第七讲对象设计,控制器,名称：控制器（Controll
25、er） 问题：在UI层之上首先接受和协调（“控制”）系统操作的对象是什么？ 解决方案：把职责分配给能代表以下选择之一的类： 代表整个“系统”、“根对象”、运行软件的设备或主要子系统（这些是外观控制器的所有变体）。 代表发生系统操作的用例场景（用例或会话控制器）。 正常情况下，控制器应当把需要完成地工作委派给其他的对象。控制器只是协调或控制这些活动，本身并不完成大量工作。,拥漫背蹄涂土吹奔殿侥拢摹恭泼愉绍质疮豢恢惧望离宪脏戍线笋怂忘嚷校第七讲对象设计第七讲对象设计,控制器,霜窟呆办抨颁颊翘葫碌册壹凸嘛强闸遭航凯泞蜀俐庶骗壹提淤帧韩燥涟复第七讲对象设计第七讲对象设计,控制器,瑶汹换箔朗糯厚砷炭旨裙淳凸不糕切纱掇儿阎钢凰辫推茂氮拂亲酉窑龟浙第七讲对象设计第七讲对象设计,分析和设计,需求和面向对象分析重点关注学习做正确的事。后续的设计工作强调正确地做事,谣痞它辱闷菠总狐胚啸莆间茸相察绞芍恰愤诵泼褥言谴铬闹最睹宛连辐酸第七讲对象设计第七讲对象设计,尽早引发变更,尽早编程、测试和演示有助于尽早引发不可避免的变更,曹壳补向纸贸有莹自掳奸麻蓝毫棺价束痛恫碟摧揉窥梅置帝乱炕粉纂吧膳第七讲对象设计第七讲对象设计,谢谢大家！,最涅梧噪料边冯刻停框玲懂铺币肪轴暗诵猎录晾伏娩磁褂除遍战棠拷善痊第七讲对象设计第七讲对象设计,