ch06_2_grasp-基于职责设计对象第17章.pptVIP

* 高内聚（High Cohesion） 模式名：高内聚 问题：怎样使对象保持有内聚、可理解和可管理，同时具有支持低耦合的附加作用？ 解决方案：职责分配应保持高内聚，依此来评估备选方案。 * 什么是高内聚度（High Cohesion） 高内聚度是对一个类中的各个职责之间相关程度和集中程度的度量。 一个具有高度相关职责的类并且这个类所能完成的工作量不是特别巨大，那么它就具有高内聚度。 包括两个意思： 不要给一个类分派太多的职责，在履行职责时尽量将部分职责分派给有能力完成的其它类去完成。 不相关的职责不要分派给同一个类。 * 图17-11 对比不同设计的内聚程度 左侧的方案中，MonopolyGame对象自己完成全部工作右侧方案中， MonopolyGame为playGame请求对工作进行了委派 * GRASP在NextGen POS设计中的示例 * 创建者模式示例：谁该负责创建SalesLineItem？ 图17-12 部分领域模型 * Sale，因为它包含了SalesLineItem 图17-13 创建SalesLineItem * 信息专家示例：谁应当负责了解销售的总额 图17-14 Sale的关联 答案：查找具有完成职责所需信息的类。 1）如果设计模型中存在相关类，则在设计模型中查找 2）否则查看领域模型，并尝试利用(或扩充)它的表示，以激发相应设计类的创建 * Sale的新职责 图17-15 部分交互图和类图 * SalesLineItem的新职责 图17-16 计算Sale的总额 * ProductDescription的新职责 图17-17 计算Sale的总额 设计类 职责 Sale 知道销售的总额 SaleLineItem 知道商品的小计 ProductDescription 知道产品的价格 * 低耦合模式示例：谁负责创建Payment 图17-18 Register创建Payment Register记录了Payment Sale具有初始化Payment的数据（支付总额），另支付是针对Sale进行的 方案一（创建者模式）： * 图17-19 Sale创建Payment 方案二（创建者模式）： 结论：方案二耦合度更低。 禁忌：高耦合对于稳定和普遍使用的元素而言不是问题。如Java库。 * 控制器模式示例：enterItem,endSale等系统操作的控制器是谁？ 图17-20 NextGen POS应用中的若干系统操作 * 图17-21 哪个对象应该是enterItem的控制器 哪个对象应该是enterItem的控制器 * 可能的选择：1.代表整个“系统”、“根对象”、装置或子系统：  Register,POSSystem2.代表用例场景中所有系统事件的接收者或处理者： ProcessSaleHandler,ProcessSaleSession. 图17-22 控制器的选择 * 不同方案的系统操作分配 图17-23 系统操作的分配 * 关于控制器模式的讨论 控制器设计中的常见缺陷是分配的职责过多。这时，控制器会具有不良(低)内聚，从而违反了高内聚的原则 准则：正常情况下，控制器应当把需要完成的工作委派给其它对象。控制器只是协调或控制这些活动，本身并不完成大量工作。 UP和Jacobson的原有对象方法中，有边界对象(接口的抽象)，实体对象(领域软件对象)和控制对象(控制器模式中的用例处理者)的概念。 控制器模式的重要结果是，UI对象和UI层不应具有实现系统事件的职责。系统操作应该在应用逻辑层或领域层完成。 * 控制器在Web UI和服务器的应用 在Web页面中混入应用逻辑是ASP.NET程序设计中常用的、脆弱的编程类型。 服务器端的Web UI框架(如：Structs)包含Web-MVC(模型-视图-控制器)模式的概念。 Web-MVC中的控制器与GRASP控制器不同，前者是UI层的一部分，并且控制UI层的交互及页面流；后者是领域层的一部分，它控制或协调工作请求的处理，它根本不知道所用的UI技术是什么？ * UI层与控制器交互的编程示例 使用Java Swing的实现：富客户端UI P222 使用Java Structs实现，客户端浏览器和WebUI P224：EnterItemAction.java * 浮肿的控制器 在系统中只有一个简单的控制器接收所有的系统事件，并且系统事件非常多。 控制器本身执行许多实现系统事件必需的任务，而没有把工作委托给别的类。 控制器本身具有许多属性，并维护着系统或者领域中本应该分布到其它对象的大量信息，或在别处可以找到的重复信息。 * 避免浮肿的控制器的一些解决方案 增加控制器。使用用例控制器，而不是外观控制器 航空预订系统示例