(零雨其蒙原创 转载请注明)

2007 年 3 月 4 日星期日

 

第 17 章 GRASP ：基于职责设计对象

P197 最关键的软件开发工具是受过良好设计原则训练的思维， 而不是 UML 或任何其他技术。

 

 

P197 总架构师利用 UML 包图 提出大型逻辑架构的构思。

 

开始设计需要输入的制品

（这些制品都是分析阶段的产物）

用例文本 定义最终必须得到软件对象的支持（对象必须能够实现实例）的可视行为。在 UP 中，这种 OO 设计也被顺理成章地称为用例实现。	补充规格说明 定义了非功能性的目标，例如国际化，我们的对象必须满足这些目标。
系统顺序图（ SSD ） 确定系统操作信息，它是合作对象交互图中的开始消息。	词汇表 明确来自 UI 层的参数或数据、传递到数据库的数据细节，以及详细的特定项逻辑或验证需求，如合法的格式和对产品 UPC （童用产品代码）的有效性验证。
操作契约 用来补充用例文本，以明确在系统操作中软件对象必须完成什么任务。后置条件定义了系统操作的详细结果	领域模型 描述了软件架构的领域层软件领域对象的名称和属性

 

 

RDD

P198  OO 设计建模的总的来说，基于职责驱动设计（ RDD ）所代表的内在含义是考虑怎样给协作中对象分配职责。

 

P200

RDD 是一种隐喻 RDD 是思考 OO 软件设计的一般性隐喻。把软件对象想象成具有某种职责的人，他要与其他人协作以完成工作。 RDD 使我们把 OO 设计看作是 有职责对象进行协作 的共同体。

 

 

职责和职责驱动设计

思考软件对象设计以及大型构件的流行方式是，考虑其职责、角色和协作。这是被称为职责驱动设计 [WM02] 大型方法的一部分。

 

软件对象的职责，即对其所作所为的抽象。 UML 把职责定义为“类元的契约和义务” [OMG03b] 。就对象的角色而言，职责与对象的义务和行为相关。职责分为以下两种类型： 行为 和 认知 。

 

对象的行为职责包括：

l         自身执行一些行为，如创建对象或计算。

l         初始化其他对象中的动作

l         控制和协调其他对象中的活动

对象的认知职责包括：

l         对私有封装数据的认知

l         对相关对象的认知

l         对其能够导出或计算的事物的认识

在对象设计中，职责分配给对象类。 例如，我可以声明“ Sale 负责创建 SalesLineItems ”（行为职责 1 ），或“ Sale 负责认知其总额”（认知职责 3 ）

 

职责与方法

职责与方法并非同一事物。 职责是一种抽象，而方法实现了职责。

职责借助于方法来实现，该方法既可以单独动作，也可以与其他方法和对象协作。

 

GRASP 与 RDD

GRASP （ General Responsibility Assignment Software Patterns 通用职责分配软件模式）对一些基本的职责分配原则进行了命名和描述，因此掌握这些原则有助于支持 RDD 。

 

2007 年 3 月 5 日星期一

GRASP 模式

Creator 创建者

名称：创建者

问题：谁创建了 A ？

解决方案：如果以下条件之一为真时（越多越好），将创建类 A 的实例的职责分配给类 B （也就是 B 创建 A ， B 应该和 A 有哪些关系或 B 应该具有哪些特征）：

l         B “包含”（比如 Board （棋盘）“包含” Square （棋盘上的方格））或组成聚集（更准确的说法是组成聚合，也称组合）了 A

l         B 记录 A

l         B 紧密地使用 A

l         B 具有 A 的初始化数据

 

 

Information Expert 信息专家

名称：信息专家

问题：给对象分配职责的基本原则是什么？

解决方案：把职责 分配 给具有完成该职责所需信息的那个类。

职责需要履行职责的信息，即关于其他对象的信息、对象自身的状态、对象周围的环境、对象能够导出的信息，等等。   

 

 

Low Coupling 低耦合

名称：低耦合

问题：如何减少因变化产生的影响？

解决方案：分配职责以使（不必要的）耦合保持在较低的水平。用该原则对可选方案进行评估。

 

 

P248 内部或自身较高的偶合度不是问题，反之与不稳定 （可能该元素今天有明天就没有了，它不是必要元素）的元素的耦合才是真正的问题所在。

 

Controller 控制器

在一些 OOA/D 方法中， 控制器 是对应用逻辑对象的命名，它接收请求并“控制”（协调）对请求的处理。

 

名称：控制器

问题：在 UI 层之上，首先接收和协调（“控制”）系统操作的对象是什么？

解决方案：把职责分配给能代表下列选择之一的对象（两类控制器）：

l         代表全部“系统”、“根对象”、运行软件的设备或主要的子系统（这些是外观控制器（ façade controller ）的所有变体）。（这种控制器是领域对象）

l         代表发生系统操作的用例场景（用例或会话控制器（ session controller ，其例子或许是 EJB 的 Session Bean ））。 P221 如果你选择用例控制器，那么对于每个用例，应用使用不同的控制器。这种控制器不是领域对象，它是支持系统的人工构造物（在 GRASP 模式的术语里是纯虚构（ Pure Fabrication ））

 

 

P221 控制器模式的重要结果是， UI 对象（例如，窗口或按钮对象）和 UI 层不应具有实现系统事件的职责。换句话说， 系统操作 应当在对象的应用逻辑层或领域层进行处理，而不是在系统的 UI 层处理。

High Cohesion 高内聚

名称：高内聚

问题：怎样使对象保持有内聚、可理解和可管理，同时具有支持低耦合的附加作用？

解决方案：职责分配应保持高内聚，依此来评估备选方案。