《GRASP基于职责设计对象》由会员分享，可在线阅读，更多相关《GRASP基于职责设计对象（49页珍藏版）》请在金锄头文库上搜索。
1、GRASP:基于职责设计对象目标n学习使用面向对象设计的5个GRASP原则或模 式UML与设计原则n最关键的软件开发工具是受过良好设计原则训 练的思维（而不是UML或其他任何技术）。n学习GRAPS和基本GoF设计模式是本书的关 键目标。职责和职责驱动设计n考虑系统中各个对象的职责、角色和协作,以 此来驱动设计的过程，称为职责驱动的设计。n职责： 类元(Classifier)的职责或义务。n职责的类型：q行为(doing)q认知(knowing)职责和职责驱动设计n行为职责：q自身执行的一些行为，如创建对象或计算q初始化其他的对象q控制和协调其他对象中的活动n认知职责q对私有封装数据的认知q对
2、相关对象的认知q对其能够导出或计算的事物的认知GRASPnGeneral Responsibility Assignment Software Patternsn使用职责进行OO设计的基本原则n帮助你理解基本对象设计，以一种系统的，合 理的，可以解释的方式来推导设计。职责、GRASP和UML图之间的关系n交互图与分配职责密切 相关：绘制交互图的过 程就是职责分配的过程 。什么是模式(pattern)n在面向对象的设计中，模式是对问题和解决方案的已 命名描述。n模式的关键元素：q名称q问题q解决方案n对于特定的问题，可以应用许多原则（模式）为对象 分配职责n模式陈述的不是新的设计思想，而是将已有
3、的，经过 验证的知识、惯用法和原则汇编起来。用到的领域模型低耦合n问题:q怎样降低依赖性，减少变化带来的影响，提高复用 性。n解决方案: q使得耦合尽可能低的方式分配职责。低耦合(cont)n什么是耦合q耦合是某元素和其他元素之间的连接、感知和依赖 程度的度量。n低耦合意味着对其他元素的依赖程度低。n高耦合导致的问题: q局部的变化影响整体q难以被单独理解q难以重用低耦合: Examplen假设我们需要创建Payment的实例，将他关联 到Sale。哪个类应该担当这个职责？PaymentRegisterSale低耦合: Example (cont):RegistermakePayment()
4、p:Payment1:create():Sale2:addPayment(p):RegistermakePayment() :Sale1:makePayment():Payment1.1:create()低耦合: Discussionn低耦合是在设计决策期间必须牢记的原则，是 应该不断被考虑的基本目标。n通常会与其他模式一起考虑，如“信息专家”或“ 高内聚”低耦合: Discussion (cont)n没有绝对的度量标准来衡量耦合程度的高低n低耦合的极端例子是没有耦合：对象间没有或极少通 信。q不可取，因为这个例子违反了对象技术的基本原则：系统由 相互连接的对象组成，对象之间通过消息通信。q耦
5、合度过低产生不良设计，其中会使用一些缺乏内聚性、膨 胀、复杂的对象来完成所有工作。q对象间适度的耦合对于一个优良的面向对象系统是非常重要 的。低耦合: Discussion (cont)n优点:q不受其它构件变化的影响q易于单独理解q便于重用n低耦合与信息隐藏低耦合：耦合的类型nTypeX 与TypeY有关系qTypeX具有TypeY的属性qTypeX直接或间接引用了TypeY，比如局部变量， 参数，或对象调用对象TypeY的服务。qTypeX是 TypeY的子类. qTypeY是接口，TypeA实现了该接口低耦合：限制n高耦合对于稳定和普遍使用的元素不是问题. 比如，J2EE应用能够安全地将
6、自己与Java库 (java.util)耦合，因为Java库是稳定、普遍使用 的。 高内聚n问题q怎样保持对象是有重点的、可理解的、可管理的，并且能够 支持低耦合n解决方案q分配职责以保持较高的内聚性。q内聚：对元素职责的相关性和集中度的度量q内聚性低的类要做许多不相关的工作，导致下列问题：n难以理解n难以复用n难以维护n经常受到变化的影响示例（低内聚）示例（高内聚）内聚程度的一些场景n非常低的内聚：由一个单独的类负责完全不同 功能领域中的大量事务n低内聚：由一个类单独负责一个功能性领域内 的复杂事务n高内聚：由一个类负责一个功能性领域内的复 杂事务，并与其它类协作完成任务。n适度内聚：类同时
7、负责几个轻量级的领域，这 些领域中的概念与该类相关，但彼此之间没有 关系。内聚与耦合的关系n低内聚通常导致高耦合。可以接受低内聚的例外n将一组职责或代码放入一个类或构件中，以使 维护人员能方便地对其进行维护。n为了提高分布式对象的效率。优点n能够更加轻松、清楚地理解设计n简化了维护和改进工作n通常支持低耦合n提高复用性创建者n问题 某类的新实例应该由谁来创建。n解决方案 如果以下的条件之一为真时，将创建类A的实 例的职责分配给BqB包含或聚集AqB具有A的初始化数据。创建者示例组合关系创建者可以通过寻找具有初始化数据的类 来确定创建者：SalePayment与低耦合模式相关,可以认为是低 耦合
8、模式在创建对象时的一个应用 。创建者n对象的创建通常具有相当的复杂性，最好的方 法是把创建职责委派给工厂(抽象或具体)类。n优点q支持低耦合n相关模式q低耦合q具体工厂和抽象工厂q整体-部分（组合模式）信息专家 (Information Expert)n问题:q给对象分配职责的基本原则是什么?n解决方案:q 将职责分配给信息专家，他拥有实现这个类所必需 的信息信息专家 (Information Expert)n在我们的系统中，谁应该负责计算销售的合计 ?Saledate timeSalesLineItemquantityProductDescriptiondescription price U
9、PCContains 1*Described-by信息专家 (Information Expert)n为了计算合计需要哪些信息?qSalesLineItem 与 Sale关联.而合计可以从 SalesLineItem 的小计算出。n因此Sale是信息专家n结束了吗?信息专家 (Information Expert)(cont)n谁负责计算SalesLineItem的小计?q需要的信息: SalesLineItem.quantity 和相关的 ProductSpecification.priceq根据信息专家模式，应该是SalesLineItem负责计算 SalesLineItem的小计类职责S
10、ale知道销售合计SalesLineItem知道明细小计ProductSpecification知道产品单价信息专家 (Information Expert)(cont)信息专家 (Information Expert) : 讨论n信息专家模式是对现实的模拟nDIY : Do It Yourself信息专家 (Information Expert) : 优点n保证了封装性q对象使用他们自己的信息来完成职责。q支持低耦合，使得系统更为健壮，更易于维护n行为分布在拥有所需信息的类中q提倡定义内聚性更强的“轻量级”类，这样的类易于 理解和维护。q通常支持高内聚信息专家 (Information Ex
11、pert):限制n在有些场合，由于高内聚和低耦合的要求，信 息专家模式并不适用。n比如，谁应该将Sale存入DB?控制器n问题:q系统事件应该由谁来处理?n解决方案:q将系统事件分配给下面的对 象:n代表整个“系统”、“根对 象” 的类。n代表用例场景的类，该事 件就是场景中发生的一个 事件 (use-case controller)q对于同一用例场景的所有系 统事件使用相同的控制器类 。n可以防止在UI层处理业务逻 辑控制器(cont)n系统事件 q由外部产生的高层的事件q系统事件不是UI事件，不是像Window/View这样的 对象。UI通过UI事件接受并组合为一个系统事件， 将其委派给控
12、制器完成。q由系统操作来执行系统事件系统事件控制器: Examplen在行为分析的过程中（比如系统顺序图），系统 操作被识别出来，并赋给 System对象。n然而，这并不是说该事件将由名为System的对象 处理。n究竟谁处理这个事件是在设计时引入的控制器对 象时分配的。SystemendSale() enterItem() makePayment() 控制器: Example (cont)n谁来处理登录商品的事件？由系统本身来处理:Register由用例处理器来处理:ProcessSaleHandlern如何选择由其他因素决定:n耦合n内聚控制器: Example (cont)确定系统事件应
13、该分 配给一个还是多个控 制器第一类控制器：Faade Controllern表示整个系统q例: Register, RetailInformationSystem, Switch, Router, NetworkInterfaceCard etc.n适用于下面情况q只有较少的系统事件第二类控制器：Use Case Controllern某个特定用例的所有事件操作定义在同一个用例控制 器中。n适用于：q不将操作分离将会违背耦合和内聚的原则（例如：臃肿的控 制器）q拥有跨越不同子系统的大量事件。实例public class EnterItemAction extends Action publi
14、c ActionForward execute( ActionMapping mapping， ActionForm form.)Repository repository = .; Register register = repository.getRegister();String txtId = (SaleForm)form).getItemID(); String txtQty = (SaleForm)form).getQuantity();ItemID id = Transformer.toItemID(txtID); int qty = Transformer.toInt(txtQty);register.enterItem(id,qty); 控制器:优点n增加了可复用的构件和插拔的潜力。n是将表示层和业务层分离的方法n能够把握用例的状态q保证系统操作是以一种合法的顺序发生控制器: 优点n用户界面对象 (windows, applets)和表示层不应该处理系统事件。q处理系统事件是领域对象的职责:SaleJFrame1:makeLineItem()onEnterItem():Sale:SaleJFrame1:enterItem()onEnterItem():Register:Sale2:makeLineItem()相关模式n命令模式n外观模式n层n纯虚构
