第17章GRASP基于职责设计对象

第17章GRASP：基于职责设计对象

GRASP:DesigningObjectswithResponsibilities1图17-1制品关系〔强调了对OO设计的影响2职责和方法UML定义职责(Responsibility)为“类元的契约或义务。方法(Method)用来实现〔履行〕职责。一个职责可能要许多类和方法(method)来实现，也可能只要很少方法来实现，这是由职责的粒度(granularity)来决定的。3职责可分成两类：“认知〞责〔knowing〕“行为〞职责〔doing〕“知道〞私有的封装数据“知道〞相关联的对象“知道〞能够派生或计算出的事物“做〞自身的一些事情。如创立一个对象或进行一次计算。“做〞其它对象的初始化操作。控制和协调其它对象的活动。4职责和交互图图17-2职责与方法是相关的在UML制品〔artifacts〕中，通常是在建立交互图的语境来考虑对象的职责分配，通过方法来实现职责。5设计模式〔Patterns〕富有经验的面向对象技术专家〔或其它软件开发人员〕为解决某些问题而设计的解决方案，可作为通用原那么(GeneralPrinciples)和惯用法(Idioms)，用于指导软件设计。如果将这些原那么和惯用法以一种结构化的形式加以描述，给出问题和解决方案，然后起一个名字。这就是设计模式(Patterns)。例如：模式名：信息专家（InformationExpert）问题：为了获取某些信息，分配职责给对象的基本原则是什么？解决方案：将职责分配给信息专家--含有满足职责所需信息的类。设计模式是一些针对特定问题的成功的解决方案6GoF关于设计模式的著作英文版于1994年出版这本书被认为是设计模式的“圣经〞，它描述了23个OO设计模式这本书的作者有四人ErichGamma,RichardHelm,RalphJohnson,JohnVlissides，因此被称为GoF〔GangofFour,四人帮〕设计模式阅读该书要有一定的OO设计和编程知识〔C++〕学习GRASP和根本GoF模式是本课程的关键目标7GRASP：分配职责通用原那么的模式GRASP作为设计模式来描述对象设计和职责分配的根本原那么。GRASP模式：创立者(Creator)信息专家(InformationExpert)低耦合(LowCoupling)控制器(Controller)高内聚(HighCohesion)GeneralResponsibilityAssignmentSoftwarePattern8创立者〔Creator〕模式名：创立者问题：谁创立了A？解决方案(可被视作建议)：如果以下条件之一成立，那么可以将创立类A实例的职责分配给类B。B包含了A对象；B组成聚集了A；B记录了A；B紧密地使用A；B具有A的初始化数据9问题：由谁创立Square对象图17-3Monopoly迭代1的领域模型10图17-4在动态模型中运用创立者模式图17-5在设计模型的DCD中，Board与Square具有组成聚合关联。我们在静态模型中应用了创立者在动态和静态模型中应用创立者模式11信息专家〔InformationExpert〕模式名：信息专家〔或专家〕问题：给对象分配职责的根本原那么是什么？解决方案(建议)：将职责分配给具有完成该职责所需信息的那个类12问题：如果给定键值，谁知道Square对象的相关信息图17-6应用专家模式13低耦合〔LowCoupling〕模式名：低耦合问题：如何减少因变化产生的影响？解决方案(建议)：分配职责以使(不必要的)耦合保持在较低的水平。使用该原那么对可选方案进行评估14图17-7评介耦合对设计影响此方案中Dog与Board都必须知道Square，而上一方案只有Board知道Square，所以上一方案耦合度更低。15为什么期望低耦合因为低耦合往往能够减少修改软件所需的时间、工作量和缺陷。16创立者模式与低耦合创立者模式支持低耦合度,意味着具有较低的依赖关系和较高的重用时机。因为被创立的类很可能早已经对创立者类可见〔即在创立者类已有方法涉及被创立者类〕，耦合程度不会增加。17信息专家模式与低耦合信息专家模式支持低耦合度。因为信息专家模式把职责分配给拥有完成职责所需信息的对象。如果我们把职责分配给其他对象，那么信息需要被这些对象共享会增加耦合度。18控制器〔Controller〕模式名：控制器问题：在UI层之上首先接收和协调(控制)系统操作的对象是什么？解决方案：将接收或处理系统事件消息的职责分派给代表以下事务的类：代表全部“系统〞或“根对象〞，如MonopolyGame对象代表运行软件的设备，如Phone，BankCashMachine代表用例或会话出现。通常命名为<用例名>Handler，<用例名>Session。如，PlayMonopolyGameHandler。19问题：谁首先来处理playGame系统系统图17-8Monopoly游戏的SSD。注意playGame操作20根据模型与视图别离原那么，UI对象不应当包括业务逻辑，应该把请求委派给领域层的对象。图17-9谁是用于playGame系统操作的控制器21如果只有少数几个系统操作，可以选择代表全部“系统〞或“根对象〞。图17-10应用控制器模式-使用MomopolyGame。所UI层与软件对象的领域层连接起来22高内聚〔HighCohesion〕模式名：高内聚问题：怎样使对象保持有内聚、可理解和可管理，同时具有支持低耦合的附加作用？解决方案：职责分配应保持高内聚，依此来评估备选方案。23什么是高内聚度〔HighCohesion〕高内聚度是对一个类中的各个职责之间相关程度和集中程度的度量。一个具有高度相关职责的类并且这个类所能完成的工作量不是特别巨大，那么它就具有高内聚度。包括两个意思：不要给一个类分派太多的职责，在履行职责时尽量将局部职责分派给有能力完成的其它类去完成。不相关的职责不要分派给同一个类。24图17-11比照不同设计的内聚程度左侧的方案中，MonopolyGame对象自己完成全部工作

右侧方案中，MonopolyGame为playGame请求对工作进行了委派25GRASP在NextGenPOS设计中的例如26创立者模式例如：谁该负责创立SalesLineItem？图17-12局部领域模型27Sale，因为它包含了SalesLineItem图17-13创立SalesLineItem28信息专家例如：谁应当负责了解销售的总额图17-14Sale的关联答案：查找具有完成职责所需信息的类。1〕如果DCD中存在相关类，那么在DCD中查找2〕否那么查看领域模型，并尝试利用(或扩充)它的表示，以激发相应设计类的创立29Sale的新职责图17-15局部交互图和类图30SalesLineItem的新职责图17-16计算Sale的总额31ProductDescription的新职责图17-17计算Sale的总额32低耦合模式例如：谁负责创立Payment图17-18Register创立PaymentRegister记录了PaymentSale具有初始化Payment的数据〔支付总额〕，另支持是针对Sale进行的方案一〔创立者模式〕：33图17-19Sale创立Payment方案二〔创立者模式〕：结论：方案二耦合度更低。禁忌：高耦合对于稳定和普遍使用的元素而言不是问题同。如Java库。34控制器模式例如：

enterItem,endSale等系统操作的控制器是谁？图17-20NextGenPOS应用中的假设干系统操作35图17-21哪个对象应该是enterItem的控制器哪个对象应该是enterItem的控制器36可能的选择：

1.代表整个“系统〞、“根对象〞、装置或子系统：

Register,POSSystem

2.代表用例场景中所有系统事件的接收者或处理者：

ProcessSaleHandler,ProcessSaleSession.图17-22控制器的选择37不同方案的系统操作分配图17-23系统操作的分配38关于控制器模式的讨论控制器设计中的常见缺陷是分配的职责过多。这时，控制器会具有不良(低)内聚，从而违反了高内聚的原那么准那么：正常情况下，控制器应当把需要完成的工作委派给其它对象。控制器只是协调或控制这些活动，本身并不完成大量工作。UP和Jacobson的原有对象方法中，有边界对象(接口的抽象)，实体对象(领域软件对象)和控制对象(控制器模式中的用例处理者)的概念。控制器模式的重要结果是，UI对象和UI层不应具有实现系统事件的职责。系统操作应该在应用逻辑层或领域层完成。39控制器在WebUI和效劳器的应用在Web页面中混入应用逻辑是ASP.NET程序设计中常用的、脆弱的编程类型。效劳器端的WebUI框架(如：Structs)包含Web-MVC(模型-视图-控制器)模式的概念。Web-MVC中的控制器与GRASP控制器不同，前者是UI层的一局部，并且控制UI层的交互及页面流；后者是领域层的一局部，它控制或协调工作请求的处理，它根本不知道所用的UI技术是什么？40UI层与控制器交互的编程例如使用JavaSwing的实现：富客户端UIP222使用JavaStructs实现，客户端浏览器和WebUIP22441浮肿的控制器在系统中只有一个简单的控制器接收所有的系统事件，并且系统事件非常多。控制器本身执行许多实现系统事件必需的任务，而没有把工作委托给别的类。控制器本身具有许多属性，并维护着系统或者领域中本应该分布到其它对象的大量信息，或在别处可以找到的重复信息。42防止浮肿的控制器的一些解决方案增加控制器。使用用例控制器，而不是外观控制器航空预订系统例如

设计控制器，使它把完成每个系统操作的职责委派给其它对象43界面层不处理系统事件-期望的图17-24UI层到领域层之间所期望的耦合44界面层不处理系统事件-不期望的图17-25UI层到领域层所不太期望的耦合45创立Payment类的对象的职责可以交给Sale类去完成。:Register