基于职责设计对象.pptVIP

高内聚度是对一个类中的各个职责之间相关程度和集中程度的度量。 一个具有高度相关职责的类并且这个类所能完成的工作量不是特别巨大，那么它就具有高内聚度。 包括两个意思： 不要给一个类分派太多的职责，在履行职责时尽量将部分职责分派给有能力完成的其它类去完成。 不相关的职责不要分派给同一个类。 * 图17-11 对比不同设计的内聚程度 左侧的方案中，MonopolyGame对象自己完成全部工作右侧方案中， MonopolyGame为playGame请求对工作进行了委派 * * 图17-12 部分领域模型 * 图17-13 创建SalesLineItem * 图17-14 Sale的关联 答案：查找具有完成职责所需信息的类。 1）如果DCD中存在相关类，则在DCD中查找 2）否则查看领域模型，并尝试利用(或扩充)它的表示，以激发相应设计类的创建 * 图17-15 部分交互图和类图 * 图17-16 计算Sale的总额 * 图17-17 计算Sale的总额 * 图17-18 Register创建Payment Register记录了Payment Sale具有初始化Payment的数据（支付总额），另支持是针对Sale进行的 方案一（创建者模式）： * 图17-19 Sale创建Payment 方案二（创建者模式）： 结论：方案二耦合度更低。 禁忌：高耦合对于稳定和普遍使用的元素而言不是问题同。如Java库。 * 图17-20 NextGen POS应用中的若干系统操作 * 图17-21 哪个对象应该是enterItem的控制器 * 图17-22 控制器的选择 * 图17-23 系统操作的分配 * 控制器设计中的常见缺陷是分配的职责过多。这时，控制器会具有不良(低)内聚，从而违反了高内聚的原则 准则：正常情况下，控制器应当把需要完成的工作委派给其它对象。控制器只是协调或控制这些活动，本身并不完成大量工作。 UP和Jacobson的原有对象方法中，有边界对象(接口的抽象)，实体对象(领域软件对象)和控制对象(控制器模式中的用例处理者)的概念。 控制器模式的重要结果是，UI对象和UI层不应具有实现系统事件的职责。系统操作应该在应用逻辑层或领域层完成。 * 在Web页面中混入应用逻辑是ASP.NET程序设计中常用的、脆弱的编程类型。 服务器端的Web UI框架(如：Structs)包含Web-MVC(模型-视图-控制器)模式的概念。 Web-MVC中的控制器与GRASP控制器不同，前者是UI层的一部分，并且控制UI层的交互及页面流；后者是领域层的一部分，它控制或协调工作请求的处理，它根本不知道所用的UI技术是什么？ * 使用Java Swing的实现：富客户端UI P222 使用Java Structs实现，客户端浏览器和WebUI P224 * 在系统中只有一个简单的控制器接收所有的系统事件，并且系统事件非常多。 控制器本身执行许多实现系统事件必需的任务，而没有把工作委托给别的类。 控制器本身具有许多属性，并维护着系统或者领域中本应该分布到其它对象的大量信息，或在别处可以找到的重复信息。 * 增加控制器。使用用例控制器，而不是外观控制器 航空预订系统示例 设计控制器，使它把完成每个系统操作的职责委派给其它对象 * 图17-24 UI层到领域层之间所期望的耦合 * 图17-25 UI层到领域层所不太期望的耦合 * 创建Payment类的对象的职责可以交给Sale类去完成。 :Register履行makaPayment职责时要履行2个职责。 方案一： Register创建Payment 图17-26 Register创建Payment * 创建Payment类的对象的职责委派给Sale类去完成。 这样，:Register履行makaPayment职责的负担减轻了。只需履行1个职责 方案二： Sale创建Payment 图17-27 Sale创建Payment 此方案既支持高内聚又支持低耦合 * * 图17-1 制品关系（强调了对OO设计的影响 * UML定义职责(Responsibility)为“类元的契约或义务。 方法(Method)用来实现（履行）职责。 一个职责可能要许多类和方法(method)来实现，也可能只要很少方法来实现，这是由职责的粒度(granularity)来决定的。 * “认知”责（knowing） “行为”职责（doing） “知道”私有的封装数据 “知道”相关联的对象 “知道”能够派生或计算出的事物 “做”自身的一些事情。如创建一个对象或进行一次计算。 “做”其它对象的初始化操作。 控制和协调其它对象的活动。 * 图17-2 职责与方法是相关的 在UML制品（