基于职责设计对象ppt课件.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 哪个对象应该是enterItem的控制器 图17 21哪个对象应该是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 高内聚模式示例 makePayment职责的分配 创建Payment类的对象的职责可以交给Sale类去完成 Register履行makaPayme