GRASP-基于职责设计对象

1第17章GRASP：基于职责设计对象GRASP:DesigningObjectswithResponsibilities2Operation:enterItem(…)Post-conditions:-...操作契约Saledate...SalesLineItemquantity1..*1......领域模型用例模型设计模型:RegisterenterItem(itemID,quantity):ProductCatalogd=getProductDescription(itemID)addLineItem(d,quantity):Sale需求业务建模设计UP制品关系示例:SystementerItem(id,quantity)用例文本系统顺序图makeNewSale()系统事件CashierProcessSale:Cashier用例名称系统操作用例图补充性规格说明词汇表用于设计的启动事件，以及需要满足的详细后置条件。ProcessSale1.Customerarrives...2....3.Cashierentersitemidentifier.启发了某些软件领域层对象的名称必须由对象实现的功能性需求对象后置条件的想法Register...makeNewSale()enterItem(...)...ProductCatalog...getProductDescription(...)...1*非功能性需求领域规则条目细节、格式、验证图17-1制品关系（强调了对OO设计的影响3职责和方法•UML定义职责(Responsibility)为“类元的契约或义务。•方法(Method)用来实现（履行）职责。•一个职责可能要许多类和方法(method)来实现，也可能只要很少方法来实现，这是由职责的粒度(granularity)来决定的。4职责可分成两类：•“认知”责（knowing）•“行为”职责（doing）•“知道”私有的封装数据•“知道”相关联的对象•“知道”能够派生或计算出的事物•“做”自身的一些事情。如创建一个对象或进行一次计算。•“做”其它对象的初始化操作。•控制和协调其它对象的活动。5职责和交互图:SalemakePayment(cashTendered):Paymentcreate(cashTendered)抽象，表示Sale对象具有创建Payment图17-2职责与方法是相关的在UML制品（artifacts）中，通常是在建立交互图的语境来考虑对象的职责分配，通过方法来实现职责。6设计模式（Patterns）富有经验的面向对象技术专家（或其它软件开发人员）为解决某些问题而设计的解决方案，可作为通用原则(GeneralPrinciples)和惯用法(Idioms)，用于指导软件设计。如果将这些原则和惯用法以一种结构化的形式加以描述，给出问题和解决方案，然后起一个名字。这就是设计模式(Patterns)。例如：模式名：信息专家（InformationExpert）问题：为了获取某些信息，分配职责给对象的基本原则是什么？解决方案：将职责分配给信息专家--含有满足职责所需信息的类。设计模式是一些针对特定问题的成功的解决方案7GoF关于设计模式的著作•英文版于1994年出版•这本书被认为是设计模式的“圣经”，它描述了23个OO设计模式•这本书的作者有四人ErichGamma,RichardHelm,RalphJohnson,JohnVlissides，因此被称为GoF（GangofFour,四人帮）设计模式•阅读该书要有一定的OO设计和编程知识（C++）学习GRASP和基本GoF模式是本课程的关键目标8GRASP：分配职责通用原则的模式GRASP作为设计模式来描述对象设计和职责分配的基本原则。GRASP模式：•创建者(Creator)•信息专家(InformationExpert)•低耦合(LowCoupling)•控制器(Controller)•高内聚(HighCohesion)GeneralResponsibilityAssignmentSoftwarePattern9创建者（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请求对工作进行了委派26GRASP在NextGenPOS设计中的示例27创建者模式示例：谁该负责创建SalesLineItem？SaletimeSalesLineItemquantityProductDescriptiondescriptionpriceitemIDDescribed-by*Contains1..*11图17-12部分领域模型28Sale，因为它包含了SalesLineItem:Register:SalemakeLineItem(quantity):SalesLineItemcreate(quantity)图17-13创建SalesLineItem29信息专家示例：谁应当负责了解销售的总额SaletimeSalesLineItemquantityProductDescriptiondescriptionpriceitemIDDescribed-by*Contains1..*11图17-14Sale的关联答案：查找具有完成职责所需信息的类。1）如果DCD中存在相关类，则在DCD中查找2）否则查看领域模型，并尝试利用(或扩充)它的表示，以激发相应设计类的创建30Sale的新职责Saletime...getTotal():Salet=getTotal新方法图17-15部分交互图和类图31SalesLineItem的新职责Saletime...getTotal()SalesLineItemquantitygetSubtotal()新方法1*:st=getSubtotal:Salet=getTotallineItems[i]:SalesLineItem这种表示法指明我们将遍历集合中的所有元素图17-16计算Sale的总额32ProductDescription的新职责Saletime...getTotal()SalesLineItemquantitygetSubtotal()ProductDescriptiondescriptionpriceitemIDgetPrice()新方法:ProductDescription1.1:p:=getPrice()1*:st=getSubtotal:Salet=getTotallineItems[i]:SalesLineItem图17-17计算Sale的总额33低耦合模式示例：谁负责创建Payment:Registerp:Payment:SalemakePayment()1:create()2:addPayment(p)图17-18Register创建Payment•Register记录了Payment•Sale具有初始化Payment的数据（支付总额），另支持是针对Sale进行的方案一（创建者模式）：34:Register:Sale:PaymentmakePayment()1:makePayment()1.1.create()图17-19Sale创建Payment方案二（创建者模式）：结论：方案二耦合度更低。禁忌：高耦合对于稳定和普遍使用的元素而言不是问题同。如Java库。35控制器模式示例：enterItem,endSale等系统操作的控制器是谁？SystemendSale()enterItem()makeNewSale()makePayment()...图17-20NextGenPOS应用中的若干系统操作36哪个对象的类应该负责接收系统事件消息？有时称为控制器或协调者。它通常不完成工作，而是将工作委派给其他对象。该控制器是从界面层到领域层的一种“外观”actionPerformed(actionEvent):???:Cashier:SaleJFrame按下按钮enterItem(itemID,qty)UI层领域层系统操作消息图17-21哪个对象应该是enterItem的控制器哪个对象应该是enterItem的控制器37可能的选择：1.代表整个“系统”、“根对象”、装置或子系统：Register,POSSystem2.代表用例场景中所有系统事件的接收者或处理者：ProcessSaleHandler,ProcessSaleSession.:RegisterenterItem(id,quantity):ProcessSaleHandlerenterItem(id,