uml8设计模式(grasp模式、gof模式)

《uml8设计模式(grasp模式、gof模式)》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、软件系统建模与设计第八部分设计模式初步计算机科学与技术学院刘鹏远waynewendy@126.com8.1设计模式的定义与作用基本概念定义对软件设计问题的可重用的解决方案。作用重用设计比重用代码更有意义，可充分利用已有的软件开发经验为设计提供共同的词汇，方便交流和书写开发文档降低错误可能性节省时间面向对象设计模式分类GRASP（GeneralResponsibilityAssignmentSoftwarePatterns,通用责任分配软件模式）GoF（GangofFour,“四人帮”设计模式）8.2面向对象设计模式分类GRASP模式责任是类间的一种合约或义务，也可以理解成一个业务功能，包括

2、行为、数据、对象的创建等知道责任——表示知道什么行为责任——表示做什么8.3.1Grasp模式基本概念GRASP模式责任＝知道责任＋行为责任了解私有封装数据了解关联的对象了解能够派生或计算的事物完成对象初始化执行一些控制行为8.3.1Grasp模式基本概念（续1）知道责任行为责任责任不是类的方法，类的方法用于实现行为责任。责任更可以理解成是系统应提供的一个业务功能责任的分配可使用顺序图或协作图来表达面向对象设计过程就是将责任分配给对象的过程8.3.1Grasp模式基本概念（续2）8.3.2Grasp模式举例行为责任表示交费的行为，需要创建一个付款记录的对象Payment。知道责任必须知道付款记

3、录类Payment，知道如何记录及计算Payment类中的数据。在一个销售业务中，存在一个交费行为，可将它识别为一个责任。发现具有交费行为的对象Sale发现了该类还关联另一个类对象Payment定义了两个部署在不同类上的方法makePayment和create8.3.2Grasp模式举例（续1）GRASP模式的分类InformationExpert（信息专家）Creator（创造者）LowCoupling（低耦合）HighCohesion（高内聚）Controller（控制器）Polymorphism（多态）PureFabrication（纯虚构）Indirection（间接）Protecte

4、dVariations（受保护变化）8.3.3Grasp模式详解8.3.3.1信息专家InformationExpert（信息专家）谁能够在某方面具有完整的信息，足以实现某个责任，就将责任分配给这个类，这个类即所谓的信息专家。总结为“谁知道谁负责”8.3.3.1Grasp模式－信息专家举例在购物车系统中，要让每个商品（Item）在购物车（ShoppingCar）中只出现一次，如果放相同的商品到车上就只更新该商品的数量而不增加商品项Creator（创造者）A是B的聚合或容器A有初始化B所需的信息A需要记录B的实例8.3.3.2创造者具有以上特性，可让A具有创建/创造B类对象的责任8.3.3.2创

5、造者举例LowCoupling（低耦合）减少类间的耦合（关联/聚集/依赖），使一个类的修改对其它类的影响范围有所降低，从而系统变得更容易维护使得系统变得更容易理解8.3.3.3低耦合总结为“不要和陌生人说话”8.3.3.3Grasp模式－低耦合举例HighCohesion（高内聚）提高类的通用性，并控制类的复杂程度，努力分解类使得类具有独立的责任。低耦合与高内聚貌似互相矛盾的两个目标。非常低的内聚：一个类单独处理很多不同模块的事务。比如它既处理对数据库的存取，又处理用户接口图形处理。比较低的内聚：一个类单独处理一个模块内的所有事务。高内聚：类只处理与模块相关的功能，一个类具有一个相对独立的责任

6、，且与其它类合作共同完成任务。8.3.3.4高内聚8.3.3.4高内聚举例准备分配新的责任时，该类中的其它功能是否与这个责任有一定的关联，如果不是，最好把责任分配给别的类，甚至新建一个类处理这个责任。问题：有一个订单类，现要增加一个用于支持存取Excel表中以支持不同数据来源的责任，这个责任应该加入订单类吗？8.3.3.4高内聚举例（续1）订单的详情和数据的存取不是同一个概念，它们甚至不相近，因此新建一个OrderDAO类来负责数据存取这个职责低内聚的缺点很难被理解和维护，可能包含近百个方法或者属性、成千上万个方法，难实现类的重用，系统脆弱不断需要修改高内聚的优点高内聚可表现关联责任的一个抽象

7、，易于实现类的重用高内聚使维护工作变得简单高内聚使得系统模块化工作，方便团队工作8.3.3.4高内聚举例（续2）8.3.3.4高内聚举例（续3）Controller（控制器）能全面代表系统或子系统的类，比如系统事件的接收和处理通常由一个高级类来代替，称为控制器类不要试图只定义一个控制器类，那样会违反高内聚的原则，一个子系统会有多个控制器类，分别处理不同的事务控制器不是用户界面类，但通常与界面类关联