《基于职责设计对象》由会员分享，可在线阅读，更多相关《基于职责设计对象（34页珍藏版）》请在金锄头文库上搜索。
1、第17章 GRASP: 基于职责设计对象,暨南大学计算机系 黄战,目标,学习使用面向对象设计的5个GRASP原则或模式,简介,决定方法归属于哪个对象和对象之间如何交互，其意义重大，应谨慎从事。 掌握OOD可以通过在实例中学习和在设计中对模式的命名,UML与设计原则,由于UML只是一种标准、可视化建模语言，了解它的细节并不能教会你如何用对象思想来思考 最关键的软件开发工具是受过良好设计原则训练的思维，而不是UML或任何其他技术,对象设计,以迭代方法的设计示例 已经完成了哪些活动？以前的活动和制品 事物之间具有什么样的关系？以前的制品对OO设计的影响 需要完成多少设计建模工作，如何完成？ 有哪些输
2、出？ 分析制品与对象设计之间有什么关系？,对象设计的输入是什么,场景 UML包图 补充规格说明 词汇表 领域模型,对象设计中的活动,给定一个或多个输入，开发者有以下3个选择： 1：立即开发编码（理想的情况是用测试优先开发方式） 2：开发为对象设计进行一些UML建模 3：利用其他建模技术，如CRC cards.,对象设计中的活动,在UML案例中，真正要关注的并不是UML，而是可视化建模，即使用一种语言，这种语言比纯文本有更强的可视化功能。 方法是使用基于职责驱动设计，考虑怎样给协作中的对象分配职责,有哪些输出？,考虑UML交互图和类图 例如： 尤其对于对象设计而言，我们期望在开始编码之前针对设计
3、中的难点创建UML交互图、类图和包图 UI的草图和原型 数据库模型 报表的草图和原型,职责和职责驱动设计,思考软件对象设计以及大型构件的流行方式是，考虑其职责、角色和协作。这些被称为职责驱动设计的大型方法的一部分。 对象职责 其所作所为的抽象,职责,类元的契约或义务 就对象的角色而言，职责与对象的义务和行为相关 职责分为两种类型： 行为： 自身执行一些行为，如创建对象或计算 初始化其他对象中的动作 控制和协调其他对象中的活动 认知： 对私有封装数据的认知 对相关对象的认知 对其能够导出或计算的事物的认知 例如：Sale负责创建SaleLineItems(行为职责) Sale负责认知其总额（认知
4、职责）,职责方法,职责的粒度会影响到类和方法的转换 职责与方法并非同一事物，职责是一种抽象，而方法实现了职责,职责协作,RDD也包括了协作的思想 职责借助于方法来实现，该方法既可以单独动作，也可以于其他方法和对象协作,职责协作,Sale类可以定义一个或多个来获取其总额，比如命名为getTotal方法。为了完成该职责，Sale可能与其他对象协作，例如每个SaleLineItem对象发送getSubtotal消息以获取其小计金额,RDD,RDD是思考OO软件设计的一般性隐喻 RDD使我们把OO设计看作是有职责对象进行协作的共同体 GRASP对一些基本的职责分配原则进行了命名和描述，因此掌握这些原则
5、有助于支持RDD,GRASP,GRASP=使用职责进行OO设计的学习工具 GRASP原则或模式是一种学习工具，它能帮助你理解基本对象设计，并且以一种系统的、合理的、可以解释的方式来运用设计推理 对这种设计原则进行理解和使用的基础是分配职责的模式,GRASP-目标,以GRASP作为工具，帮助掌握OOD的基本知识并理解对象设计中的职责分配,职责、 UML 、GRASP,在UML中，绘制交互图是考虑这些职责（实现为方法）的时机 GRASP中的基本原则可以指导分配职责，当绘制UML交互图以及编写代码时，就可以运用GARSP原则了。,什么是模式？,模式： 有经验的OO开发者建立了既有通用原则又有惯用方案
6、的指令系统来指导他们编制软件 在OO设计中，模式是对问题和解决方案的已命名描述，它可以用于新的语境 理想情况下，模式为在变化环境中如何运用和权衡其解决方案给出建议,好的模式,简单地讲，好的模式是成对的问题/解决方案，并且具有广为人知的名称，它能用于新的语境中，同时对新情况下的应用、权衡、实现、变化等给出了建议,GoF,Gang of Four(GoF) 设计模式Gamma,Helm,Johnson,and Vlissides 23个OO设计模式,GRASP,定义了9个基本OO设计原则或基本设计构件 某人的模式是其他人的原始构造块,OO设计背景,1：迭代过程背景有哪些优先制品？它们与OO设计模型
7、有什么关系？我们应当花费多少时间进行设计建模？ 2：作为对象设计隐喻的RDD：有职责对象协作的共同体 3：作为OO设计思想命名和解释方式的模式：分配职责的基本模式是GRASP，对于更为高级的设计思想则应用GoF模式。模式可在建模期间和编码期间应用 4：UML用于OO设计的可视建模，在此期间，GRASP和GoF模式都能使用,GRASP的示例,17.8,使用GRASP进行对象设计,共有9个GRASP模式，本案例只应用一下几个： 创建者 信息专家 低耦和 控制器 高内聚,创建者,问题: 谁有责任来创建类的实例？,创建者,解决方案：B是A实例的创建者 如果以下条件之一为真时（越多越好），将创建类A实例
8、的职责分配给类B: B”包含”或组成聚集了A B记录A B紧密地使用A B具有A的初始化数据,信息专家,问题：给对象分配职责的基本原则是什么？ 解决方案：把职责分配给具有完成该职责所需信息的那个类,低耦合,问题： 怎样降低依赖性，减少变化带来的影响，提高重用性？ 耦合是对某元素之间的连接、感知和依赖程度的度量。具有低（或弱）耦合的元素不会包括类、子系统、系统等 具有高（或强）耦合的类依赖于许多其他的类，这样的类或许不是我们所需要的。有些类会遇到以下问题： 由于相关类的变化而导致本体的被迫变化 难以单独地理解 由于使用高耦合类时需要它所依赖的类，因此很难重用,低耦合,解决方案： 分配职责，使耦合
9、性尽可能低。利用这一原则来评估可选方案 在实践中，耦合程度不能脱离专家、高内聚等其他原则孤立地考虑。不过，它的确是改进设计所要考虑的因素之一,控制器,问题： 在UI 层之上首先接收和协调（控制）系统操作的第一个对象是什么？ 在SSD分析期间，要首先探讨系统操作。这些是我们系统的主要输入事件。例如，当使用POS终端的收银员按下“结束销售”按钮时，他就发起了表示“销售已经终止”的系统事件。类似地，当使用文字处理器的书写者按下“拼写检查”按钮时，他就发起了表示“执行拼写检查”的系统事件 控制器是UI层之上的第一个对象，它负责接收和处理系统操作消息,控制器,解决方案： 把职责分配给能代表以下选择之一的
10、类： 代表整个“系统”、“根对象”、运行软件的设备或主要子系统，这些是外观控制器的所有变体。 代表用例场景，在该场景中发生系统事件，通常命名为Handler、Coordinator或Session（用例或会话控制器）。 对于同一用例场景的所有系统事件使用相同的控制器类 通俗地说，会话是参与者进行交谈地实例。会话可以具有任意长度，但通常按照用例来组织（用例会话） 正常情况下，控制器应当把需要完成地工作委派给其他的对象。控制器只是协调或控制这些活动，本身并不完成大量工作。,高内聚,问题： 怎样保持对象是有重点的、可理解的、可管理的，并且能够支持低耦合？ 从对象设计的角度上说，内聚（或更为专业地说，是功能内聚）是对元素职责的相关性和集中度的度量。如果元素具有高度相关的职责，而且没有过多工作，那么该元素具有高内聚性。这些元素包括类、子系统等等。,高内聚,解决方案： 分配职责可保持较高的内聚性。可利用这一点来评估候选方案。 内聚性较低的类要做的许多互不相关的工作，或需要完成大量的工作。这样的类是不合理的，它们会导致以下问题： 难以理解 难以复用 难以维护 脆弱，经常会受到变化的影响 内聚性低的类通常表示大粒度的抽象，或承担了本应委托给其他对象的职责 在实践中，内聚程度不能脱离其他职责及其他原则（如专家和低耦合）单独地考虑,
