UML学习——GRASP：基于职责设计对象

1.模式的定义：有经验的OO开发者（以及其他的软件开发者）建立了既有通用原则又有惯用方案的指令系统来指导他们编制软件。如果以结构化形式对这些问题、解决方案和命名进行描述使其系统化，那么这些原则和习惯用法就可以成为模式。

~~模式具有名称。GRASP模式陈述的并不是新思想，而只是为广泛使用的进本原则命名并将其汇总起来。

（一）创建者（creator）模式

1.定义：

名称：创建者（creator）

问题：谁创建了A？

解决方案（可被视作建议）：如果一下条件之一为真时（越多越好），将创建类A实例的职责分配给B：

B“包含”或组成聚集了A、B记录A、B紧密地使用A、B具有A的初始化数据。
【注】A和B指定是软件对象，而不是领域模型对象。

（二）信息专家（information expert）

 

（三）低耦合（low coupling）模式

1.耦合是对某元素与其他元素之间的连接、感知和依赖程度的度量。具有低耦合的元素不会过度依赖于其他元素。

（四）高内聚（high cohesion）模式

1.内聚（更专业的说，是功能内聚）是对元素职责的相关性和集中度的度量。如果元素具有高度相关的职责，且没有过多工作，那么该元素具有高内聚性。

 

（五）控制器（controller）模式

1.定义：控制器是UI层之上的第一个对象 ——负责接受和处理系统操作消息。控制器模式考虑的问题是：在UI层之上首先接收和协调（控制）系统操作的第一个对象是什么。

2.解决方案：把职责分配给能代表一下选择之一的类：

（1）代表整个“系统”、“根对象”、运行软件的设备或主要子系统，这些事外观控制器的所有变体。

（2）代表用例场景，在该场景中发生系统事件，通常命名为<UseCaseName>Handler或<UseCaseName>Coordinator或<UseCaseName>Session。

（3）对于同一用例场景的所有系统事件使用相同的控制器类。

（4）会话是与参与者进行交谈的实例。会话可以具有任意长度，但通常按照用例来组织（用例会话）

 

整理不易，亲亲点个赞呗~~