GRASP基于职责设计对象学习培训模板课件.ppt

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交互图与分配职责密切相关：绘制交互图的过程就是职责分配的过程。:SalemakePayment(cashTendered):Paymentcreate(cashTendered)abstract,implies Sale objects have a responsibility to create Pa

3、yments什么是模式(pattern)n在面向对象的设计中，模式是对问题和解决方案的已命名描述。n模式的关键元素：q名称q问题q解决方案n对于特定的问题，可以应用许多原则（模式）为对象分配职责n模式陈述的不是新的设计思想，而是将已有的，经过验证的知识、惯用法和原则汇编起来。用到的领域模型低耦合n问题:q怎样降低依赖性，减少变化带来的影响，提高复用性。n解决方案:q使得耦合尽可能低的方式分配职责。低耦合(cont)n什么是耦合q耦合是某元素和其他元素之间的连接、感知和依赖程度的度量。n低耦合意味着对其他元素的依赖程度低。n高耦合导致的问题:q局部的变化影响整体q难以被单独理解q难以重用低耦合:

4、Examplen假设我们需要创建Payment的实例，将他关联到Sale。哪个类应该担当这个职责？PaymentRegisterSale低耦合:Example(cont):RegistermakePayment()p:Payment1:create():Sale2:addPayment(p):RegistermakePayment():Sale1:makePayment():Payment1.1:create()低耦合:Discussionn低耦合是在设计决策期间必须牢记的原则，是应该不断被考虑的基本目标。n通常会与其他模式一起考虑，如“信息专家”或“高内聚”低耦合:Discussion(co

5、nt)n没有绝对的度量标准来衡量耦合程度的高低n低耦合的极端例子是没有耦合：对象间没有或极少通信。q不可取，因为这个例子违反了对象技术的基本原则：系统由相互连接的对象组成，对象之间通过消息通信。q耦合度过低产生不良设计，其中会使用一些缺乏内聚性、膨胀、复杂的对象来完成所有工作。q对象间适度的耦合对于一个优良的面向对象系统是非常重要的。低耦合:Discussion(cont)n优点:q不受其它构件变化的影响q易于单独理解q便于重用n低耦合与信息隐藏低耦合：耦合的类型nTypeX 与TypeY有关系qTypeX具有TypeY的属性qTypeX直接或间接引用了TypeY，比如局部变量，参数，或对象调

6、用对象TypeY的服务。qTypeX是 TypeY的子类.qTypeY是接口，TypeA实现了该接口低耦合：限制n高耦合对于稳定和普遍使用的元素不是问题.比如，J2EE应用能够安全地将自己与Java库(java.util)耦合，因为Java库是稳定、普遍使用的。高内聚n问题q怎样保持对象是有重点的、可理解的、可管理的，并且能够支持低耦合n解决方案q分配职责以保持较高的内聚性。q内聚：对元素职责的相关性和集中度的度量q内聚性低的类要做许多不相关的工作，导致下列问题：n难以理解n难以复用n难以维护n经常受到变化的影响示例（低内聚）示例（高内聚）:Register:SalemakePayment()

7、:Paymentcreate()makePayment()内聚程度的一些场景n非常低的内聚：由一个单独的类负责完全不同功能领域中的大量事务n低内聚：由一个类单独负责一个功能性领域内的复杂事务n高内聚：由一个类负责一个功能性领域内的复杂事务，并与其它类协作完成任务。n适度内聚：类同时负责几个轻量级的领域，这些领域中的概念与该类相关，但彼此之间没有关系。内聚与耦合的关系n低内聚通常导致高耦合。可以接受低内聚的例外n将一组职责或代码放入一个类或构件中，以使维护人员能方便地对其进行维护。n为了提高分布式对象的效率。优点n能够更加轻松、清楚地理解设计n简化了维护和改进工作n通常支持低耦合n提高复用性创建

8、者n问题某类的新实例应该由谁来创建。n解决方案如果以下的条件之一为真时，将创建类A的实例的职责分配给BqB包含或聚集AqB具有A的初始化数据。创建者示例SaletimeSalesLineItemquantityProductDescriptiondescriptionpriceitemIDDescribed-by*Contains1.*11:Register:SalemakeLineItem(quantity):SalesLineItemcreate(quantity)组合关系组合关系创建者创建者可以通过寻找具有初始化数据的可以通过寻找具有初始化数据的类来确定创建者：类来确定创建者：SaleS

9、alePaymentPayment与低耦合模式相关与低耦合模式相关,可以认为是低可以认为是低耦合模式在创建对象时的一个应用。耦合模式在创建对象时的一个应用。创建者n对象的创建通常具有相当的复杂性，最好的方法是把创建职责委派给工厂(抽象或具体)类。n优点q支持低耦合n相关模式q低耦合q具体工厂和抽象工厂q整体-部分（组合模式）信息专家(Information Expert)n问题:q给对象分配职责的基本原则是什么?n解决方案:q 将职责分配给信息专家，他拥有实现这个类所必需的信息信息专家(Information Expert)n在我们的系统中，谁应该负责计算销售的合计?SaledatetimeS

10、alesLineItemquantityProductDescriptiondescriptionpriceUPCContains1.*Described-by信息专家(Information Expert)n为了计算合计需要哪些信息?qSalesLineItem 与 Sale关联.而合计可以从SalesLineItem 的小计算出。n因此Sale是信息专家n结束了吗?信息专家(Information Expert)(cont)n谁负责计算SalesLineItem的小计?q需要的信息:SalesLineItem.quantity 和相关的ProductSpecification.priceq

11、根据信息专家模式，应该是SalesLineItem负责计算SalesLineItem的小计类类职责职责Sale知道销售合计SalesLineItem知道明细小计ProductSpecification知道产品单价信息专家(Information Expert)(cont)Saletime.getTotal()SalesLineItemquantitygetSubtotal()ProductDescriptiondescriptionpriceitemIDgetPrice()New method:ProductDescription1.1:p:=getPrice()1*:st=getSubtot

12、al:Salet=getTotallineItems i :SalesLineItem信息专家(Information Expert):讨论n信息专家模式是对现实的模拟nDIY:Do It Yourself信息专家(Information Expert):优点n保证了封装性q对象使用他们自己的信息来完成职责。q支持低耦合，使得系统更为健壮，更易于维护n行为分布在拥有所需信息的类中q提倡定义内聚性更强的“轻量级”类，这样的类易于理解和维护。q通常支持高内聚信息专家(Information Expert):限制限制n在有些场合，由于高内聚和低耦合的要求，信息专家模式并不适用。n比如，谁应该将Sal

13、e存入DB?控制器n问题:q系统事件应该由谁来处理?n解决方案:q将系统事件分配给下面的对象:n代表整个“系统”、“根对象”的类。n代表用例场景的类，该事件就是场景中发生的一个事件(use-case controller)q对于同一用例场景的所有系统事件使用相同的控制器类。n可以防止在UI层处理业务逻辑Which class of object should be responsible for receiving this system event message?It is sometimes called the controller or coordinator.It does not

14、 normally do the work,but delegates it to other objects.The controller is a kind of facade onto the domain layer from the interface layer.actionPerformed(actionEvent):?:Cashier:SaleJFramepresses buttonenterItem(itemID,qty)UI LayerDomain Layersystem operation message控制器(cont)n系统事件系统事件 q由外部产生的高层的事件q系统

15、事件不是UI事件，不是像Window/View这样的对象。UI通过UI事件接受并组合为一个系统事件，将其委派给控制器完成。q由系统操作来执行系统事件enterItem(itemID,quantity):System:CashierendSalemakePayment(amount)a UML loop interaction frame,with a boolean guard expressionexternal actor to systemProcess Sale Scenariosystem as black boxthe name could be NextGenPOS but Sy

16、stem keeps it simplethe:and underline imply an instance,and are explained in a later chapter on sequence diagram notation in the UMLa message with parametersit is an abstraction representing the system event of entering the payment data by some mechanismdescription,totalreturn value(s)associated wit

17、h the previous messagean abstraction that ignores presentation and medium the return line is optional if nothing is returnedtotal with taxeschange due,receiptmakeNewSale more items loop系统事件Which class of object should be responsible for receiving this system event message?It is sometimes called the

18、controller or coordinator.It does not normally do the work,but delegates it to other objects.The controller is a kind of facade onto the domain layer from the interface layer.actionPerformed(actionEvent):?:Cashier:SaleJFramepresses buttonenterItem(itemID,qty)UI LayerDomain Layersystem operation mess

19、age控制器:Examplen在行为分析的过程中（比如比如系统顺序图），系统操作被识别出来，并赋给 System对象。n然而，这并不是说该事件将由名为System的对象处理。n究竟谁处理这个事件是在设计时引入的控制器对象时分配的。SystemendSale()enterItem()makePayment().控制器:Example(cont)n谁来处理登录商品的事件？由系统本身来处理:Register由用例处理器来处理:ProcessSaleHandlern如何选择由其他因素决定:n耦合n内聚:RegisterenterItem(id,quantity):ProcessSaleHandlere

20、nterItem(id,quantity)控制器:Example(cont)Register.endSale()enterItem()makeNewSale()makePayment()makeNewReturn()enterReturnItem().SystemendSale()enterItem()makeNewSale()makePayment()makeNewReturn()enterReturnItem().system operations discovered during system behavior analysisallocation of system operatio

21、ns during design,using one facade controllerProcessSaleHandler.endSale()enterItem()makeNewSale()makePayment()SystemendSale()enterItem()makeNewSale()makePayment()enterReturnItem()makeNewReturn().allocation of system operations during design,using several use case controllersHandleReturnsHandler.enter

22、ReturnItem()makeNewReturn().确定系统事件应该分配给一个还是多个控制器第一类控制器：Faade Controllern表示整个系统q例:Register,RetailInformationSystem,Switch,Router,NetworkInterfaceCard etc.n适用于下面情况q只有较少的系统事件第二类控制器：Use Case Controllern某个特定用例的所有事件操作定义在同一个用例控制器中。n适用于：q不将操作分离将会违背耦合和内聚的原则（例如：臃肿的控制器）q拥有跨越不同子系统的大量事件。实例public class EnterItemA

23、ction extends Actionpublic 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纯虚构