GRASP-基于职责设计对象.ppt

1,第17章GRASP：基于职责设计对象GRASP:DesigningObjectswithResponsibilities,2,图17-1制品关系（强调了对OO设计的影响,3,职责和方法,UML定义职责(Responsibility)为“类元的契约或义务。方法(Method)用来实现（履行）职责。一个职责可能要许多类和方法(method)来实现，也可能只要很少方法来实现，这是由职责的粒度(granularity)来决定的。,4,职责可分成两类：,“认知”责（knowing）“行为”职责（doing）,“知道”私有的封装数据“知道”相关联的对象“知道”能够派生或计算出的事物,“做”自身的一些事情。如创建一个对象或进行一次计算。“做”其它对象的初始化操作。控制和协调其它对象的活动。,5,职责和交互图,图17-2职责与方法是相关的,在UML制品（artifacts）中，通常是在建立交互图的语境来考虑对象的职责分配，通过方法来实现职责。,6,设计模式（Patterns）,富有经验的面向对象技术专家（或其它软件开发人员）为解决某些问题而设计的解决方案，可作为通用原则(GeneralPrinciples)和惯用法(Idioms)，用于指导软件设计。如果将这些原则和惯用法以一种结构化的形式加以描述，给出问题和解决方案，然后起一个名字。这就是设计模式(Patterns)。,7,GoF关于设计模式的著作,英文版于1994年出版这本书被认为是设计模式的“圣经”，它描述了23个OO设计模式这本书的作者有四人ErichGamma,RichardHelm,RalphJohnson,JohnVlissides，因此被称为GoF（GangofFour,四人帮）设计模式阅读该书要有一定的OO设计和编程知识（C+）,学习GRASP和基本GoF模式是本课程的关键目标,8,GRASP：分配职责通用原则的模式,GRASP作为设计模式来描述对象设计和职责分配的基本原则。,GRASP模式：创建者(Creator)信息专家(InformationExpert)低耦合(LowCoupling)控制器(Controller)高内聚(HighCohesion),GeneralResponsibilityAssignmentSoftwarePattern,9,创建者（Creator）,模式名：创建者问题：谁创建了A？解决方案(可被视作建议)：如果以下条件之一成立，则可以将创建类A实例的职责分配给类B。B包含了A对象；B组成聚集了A；B记录了A；B紧密地使用A；B具有A的初始化数据,10,问题：由谁创建Square对象,图17-3Monopoly迭代1的领域模型,11,图17-4在动态模型中运用创建者模式,图17-5在设计模型的DCD中，Board与Square具有组成聚合关联。我们在静态模型中应用了创建者,在动态和静态模型中应用创建者模式,12,信息专家（InformationExpert）,模式名：信息专家（或专家）问题：给对象分配职责的基本原则是什么？解决方案(建议)：将职责分配给具有完成该职责所需信息的那个类,13,问题：如果给定键值，谁知道Square对象的相关信息,图17-6应用专家模式,14,低耦合（LowCoupling）,模式名：低耦合问题：如何减少因变化产生的影响？解决方案(建议)：分配职责以使(不必要的)耦合保持在较低的水平。使用该原则对可选方案进行评估,15,图17-7评介耦合对设计影响,此方案中Dog与Board都必须知道Square，而上一方案只有Board知道Square，所以上一方案耦合度更低。,16,为什么期望低耦合,因为低耦合往往能够减少修改软件所需的时间、工作量和缺陷。,17,创建者模式与低耦合,创建者模式支持低耦合度,意味着具有较低的依赖关系和较高的重用机会。因为被创建的类很可能早已经对创建者类可见（即在创建者类已有方法涉及被创建者类），耦合程度不会增加。,18,信息专家模式与低耦合,信息专家模式支持低耦合度。因为信息专家模式把职责分配给拥有完成职责所需信息的对象。如果我们把职责分配给其他对象，则信息需要被这些对象共享会增加耦合度。,19,控制器（Controller）,模式名：控制器问题：在UI层之上首先接收和协调(控制)系统操作的对象是什么？解决方案：将接收或处理系统事件消息的职责分派给代表下列事务的类：代表全部“系统”或“根对象”，如MonopolyGame对象代表运行软件的设备，如Phone，BankCashMachine代表用例或会话出现。通常命名为Handler，Session。如，PlayMonopolyGameHandler。,20,问题：谁首先来处理playGame系统系统,图17-8Monopoly游戏的SSD。注意playGame操作,21,根据模型与视图分离原则，UI对象不应当包括业务逻辑，应该把请求委派给领域层的对象。,图17-9谁是用于playGame系统操作的控制器,22,如果只有少数几个系统操作，可以选择代表全部“系统”或“根对象”。,图17-10应用控制器模式-使用MomopolyGame。所UI层与软件对象的领域层连接起来,23,高内聚（HighCohesion）,模式名：高内聚问题：怎样使对象保持有内聚、可理解和可管理，同时具有支持低耦合的附加作用？解决方案：职责分配应保持高内聚，依此来评估备选方案。,24,什么是高内聚度（HighCohesion）,高内聚度是对一个类中的各个职责之间相关程度和集中程度的度量。一个具有高度相关职责的类并且这个类所能完成的工作量不是特别巨大，那么它就具有高内聚度。,包括两个意思：不要给一个类分派太多的职责，在履行职责时尽量将部分职责分派给有能力完成的其它类去完成。不相关的职责不要分派给同一个类。,25,图17-11对比不同设计的内聚程度,左侧的方案中，MonopolyGame对象自己完成全部工作右侧方案中，MonopolyGame为playGame请求对工作进行了委派,26,GRASP在NextGenPOS设计中的示例,27,创建者模式示例：谁该负责创建SalesLineItem？,图17-12部分领域模型,28,Sale，因为它包含了SalesLineItem,图17-13创建SalesLineItem,29,信息专家示例：谁应当负责了解销售的总额,图17-14Sale的关联,答案：查找具有完成职责所需信息的类。1）如果DCD中存在相关类，则在DCD中查找2）否则查看领域模型，并尝试利用(或扩充)它的表示，以激发相应设计类的创建,30,Sale的新职责,图17-15部分交互图和类图,31,SalesLineItem的新职责,图17-16计算Sale的总额,32,ProductDescription的新职责,图17-17计算Sale的总额,33,低耦合模式示例：谁负责创建Payment,图17-18Register创建Payment,Register记录了PaymentSale具有初始化Payment的数据（支付总额），另支持是针对Sale进行的,方案一（创建者模式）：,34,图17-19Sale创建Payment,方案二（创建者模式）：,结论：方案二耦合度更低。禁忌：高耦合对于稳定和普遍使用的元素而言不是问题同。如Java库。,35,控制器模式示例：enterItem,endSale等系统操作的控制器是谁？,图17-20NextGenPOS应用中的若干系统操作,36,图17-21哪个对象应该是enterItem的控制器,哪个对象应该是enterItem的控制器,37,可能的选择：1.代表整个“系统”、“根对象”、装置或子系统：Register,POSSystem2.代表用例场景中所有系统事件的接收者或处理者：ProcessSaleHandler,ProcessSaleSession.,图17-22控制器的选择,38,不同方案的系统操作分配,图17-23系统操作的分配,39,关于控制器模式的讨论,控制器设计中的常见缺陷是分配的职责过多。这时，控制器会具有不良(低)内聚，从而违反了高内聚的原则准则：正常情况下，控制器应当把需要完成的工作委派给其它对象。控制器只是协调或控制这些活动，本身并不完成大量工作。UP和Jacobson的原有对象方法中，有边界对象(接口的抽象)，实体对象(领域软件对象)和控制对象(控制器模式中的用例处理者)的概念。控制器模式的重要结果是，UI对象和UI层不应具有实现系统事件的职责。系统操作应该在应用逻辑层或领域层完成。,40,控制器在WebUI和服务器的应用,在Web页面中混入应用逻辑是ASP.NET程序设计中常用的、脆弱的编程类型。服务器端的WebUI框架(如：Structs)包含Web-MVC(模型-视图-控制器)模式的概念。Web-MVC中的控制器与GRASP控制器不同，前者是UI层的一部分，并且控制UI层的交互及页面流；后者是领域层的一部分，它控制或协调工作请求的处理，它根本不知道所用的UI技术是什么？,41,UI层与控制器交互的编程示例,使用JavaSwing的实现：富客户端UIP222使用JavaStructs实现，客户端浏览器和WebUIP224,42,浮肿的控制器,在系统中只有一个简单的控制器接收所有的系统事件，并且系统事件非常多。控制器本身执行许多实现系统事件必需的任务，而没有把工作委托给别的类。控制器本身具有许多属性，并维护着系统或者领域中本应该分布到其它对象的大量信息，或在别处可以找到的重复信息。,43,避免浮肿的控制器的一些解决方案,增加控制器。使用用例控制器，而不是外观控制器航空预订系统示例设计控制器，使它把完成每个系统操作的职责委派给其它对象,44,界面层不处理系统事件-期望的,图17-24UI层到领域层之间所期望的耦合,45,界面层不处理系统事件-不期望的,图17-25UI层到领域层所不太期望的耦合,46,创建Payment类的对象的职责可以交给Sale类去完成。,:Register履行maka