-
GRASP
（中文版）
——
General Responsibility
Assignment Software
patterns
（通用职责分配软件模式）
它的核心思想是“职责分配（
Responsibility
Assignment
）
”
。
GRASP
提出了几个基本原则，用
来解决面向
对象设计的一些问题。
Craig
Larman
氏在《
Applying UML and Pa
tterns
》一书中提出了
GRASP
设计模式的概念。作者
称其为设计模式，
其实，
更好的理解应该为设计原则。
因为，
与
GoF
等设计模式不同的是，
GoF
等设计模式是针对特定问题而提出的解决方法，而
GRASP
< br>则是站在面向对象设计的角
度，
告诉我们怎么样设计问题
空间中的类与它们的行为责任，
以及明确类之间的相互关系等
等
。
GRASP
可以说是
GoF
等设计模式的基础。
GRASP
概要
它包含了
9
个基本模式：
1
，
信息专家
(In
formation expert)
2
，
创建者（
Creator)
3
，
高内聚
(
High Cohesion)
4
，
低耦合
(Low coupling)
5
，
控制器
(
Controller)
6
，
多态性
(Polymorphism)
7
，
纯虚构
(Pu
re Fabrication)
8
，
间接性
(Indirection)
9
，
变化预防
(Protected Variations)
GRASP
的主要特征：
?
对象职责分配的基本原则。
?
主要应用在分析和建模上。
GRASP
的核心思想的理解：
自己干自己的事（职责的分配）
自己干自己的能干的事（职责的分配）
自己只干自己的事（职责的内聚）
面向对象设计
所谓面向对象设计，<
/p>
就是在系统设计的过程中，
通过把系统分成相对独立但又互相联系
的对
象组合的一种设计方法。
对象具
有属性和行为，对象间通过消息进行交互（协作）
。
面向对象设计一般有以下几个关键步骤：
1
，
发现对象。找出系统应该由哪些对象构成。
2
，
对象的属性。对象具有哪些属性。
3
，
对象的
行为。对象具有哪些行为；或者说对象需要做什么，它的职责是什么。
4
，
对象的
关系。对象与对象之间的关系是什么，怎样进行交互，协作等等。
发现对象
对象的发现超出了本文的讨
论范围。我们简单地介绍一下对象发现的过程与手段。
一般意
义上的对象是现实世界上物体的抽象。
也就是说，
现实世界里有
什么物体，
就有什么
对象；物体存在什么属性，对象就有什么属
性。
我们可以用“名词筛选法”来发现系统的对象。
比如，一个学生考试成绩管理系统，有以下简单的用例：
-
管理员创建题库（把题条加入题库）
-
系统根据管理员输入的某些条件随机生成试题
-
学生成绩入库与管理
我们可以通过字面意思找出名词，就可以找出“管理员“，
“题条”
，
“题库”
，
“试题
”
，
“学
生”
，
“学生成绩”等几个对象。
一般通过这种方法（名词筛选法）就可以找出系统的绝大部分对象。
对象行为
行为是对象应该执行的动作
，
也就是对象的职责。
对象具有哪些职责呢？相对于上面所说的
“名词筛选法”
，可以简单地用“动词筛选法”来发现“对象的
行为”
。
比如，上面的“学生考试成
绩管理系统”一例中，有“创建题库”
，
“输入（条件）
”
，
“生成
试题”<
/p>
，
“成绩入库”
，
“成绩管理”
等动词，
也就是说，
系
统的对象至少具有以上这些行为
（或
职责）
。
有时，
我们可能还会发现某些
“行为”
的粒度过大，
这时，
可以通过进一步细化用例的描述，
来发现更多更细的“行为”
。这里不再详述。
问题
1
：找出对象的行为（职责）之后，怎么样分配这些行为呢？也就是说怎么确认
“
行为
”
属于哪个对象
呢？
对象关系
系统的所有对象不可能是一个个单独存在毫无关系的个体，它们或多或少的有着各种联系
（协作关系）
。
问题
2
：如果
2
个对象之间有
协作关系，他们之间最好通过什么样的方式协作呢？
对象扩展特性
问题
< br>3
：已经被抽象出来的对象，如何面对将来可能发生的变化呢？
< br>
GRASP
提出
9
个基本模式，用于解决以上设计过程中遇到的各种问题。
GRASP
Information Expert Pattern -
Grasp
之
信息专家模式
信息专家模式
（
Information Ex
pert
）
是
GRASP
模式中解决类的职责分配问题的最基本的模式。
问题：
当我们为系统发现完对象和职
责之后，
职责的分配原则
（职责将分配给哪个对象执行）
是什
么？
解决方案：
职责的执行需要某些信息
（
information
）
，
把职责分配给该信息的拥有者
。
换句话说，某项职责的执行需要某些资源，只有拥有这些资源的对象才有资格执行职责。< p>
这有点类似现实世界的“有能者为之”的概念。你有建筑知识，可以去执
行盖楼的职责；你
有法律知识，可以去裁判案件等等。
满足了面向对象设计的封装性的设计，一般情况下都会满足
Infor
mation
Expert
模式。因为
Information
Expert
是对类的属性（信息
）
，以及对类的属性的操作的封装，它符合对象封装
性的概念。
优点：
-
信息的拥有者类同时就是信息的操作者类，可以减少不必要的类之间的关联。
-
各类的职责单一明确，容易理解
Information
Expert
例
为了说明问题，我们
使用“学生成绩管理系统”中的用例
1
来说明。
用例
1
：
-
管理员创建题库（把题条加入题库）
再细化一下：
-
< br>管理员创建题库（把题条加入题库）
：如果题库中已经存在所给的题条，则退出，
否则加
入题条。
这样就存在
3
个对象：管理员用户
User
，题条
SubjectItem
，题库
SubjectLibrary
2
个职责：判断（新
加入的题条是否与题库某题条相等）
，加入（题条的加入）
这
2
个职责
究竟应该由哪个对象执行？
我们使用
Information
Expert
模式来分析。
1
，
判断<
/p>
2
个题条是否相等，只要判断题条的
ID
属性（或其它属性）是否相等就可以了。
题条的
ID
是属于题条的，所以对它的操作应该放在题条
Su
bjectItem
里。
2
，
题条的
加入需要操作的数据有
2
部分，
一部分
是新加入的题条本身，
另一部分是题库
（加
入到题库）
，
题条是题库的一部分，
所以题条的加入应该放在题库
SubjectLibrary
里完成。
如图：
< br>如果把以上
2
个职责放在第三方类中，无疑增加了它们与
第三方类之间的耦合关系。
GRASP Creator Pattern -
GRASP
之创建者模式
创建者模式
（
Creator
）是
GRASP
模式中解决类的实例的创建职责问题的模式。
问题
类的实例的创建职责，应该分配
给什么样的类？或者说类的实例应该由谁创建？
Creator
模式所提倡的解决方案
以下条件之一为真的情况，类
A
的实例
的创建职责就分配给类
B
。
1
，
B
包含
A
2
，
B
聚集
A
3
，
B
记录
A
4
，
B
频繁使用
A
5
，
B
有
A
初始化数据
Creator
模式提倡类的实例（
对象）创建职责由聚集或包含该对象的对象创建。
注：
Creator
模式只是一个原则，如果类
A
，
B
之间没有包含或聚集关系，应该先
考案是否有
“
B
记录
< br>A
”
，或者“
B
有
A
初始化数据”的关系，然后是“
< br>B
频繁使用
A
”的关系。另外，
作为代替方案，一般的采用工厂（
Factory
）创建方案。
如果不遵循
Creator
模式，
把类的实例的创建职责交给无关的类，<
/p>
类之间的关系变得复杂化，
降低系统的可维护性和可扩展性。
一般来说，应用
Creator
模式，可以从上之下设计好类之间的包含或聚集关系阶层图，让每
个类负
责创建自己包含的类的实例。
应用
C
reator
模式的好处
-
-
-
整个结构清晰易懂
有利于类或组件的重用
防止职责的分散
-
降低耦合性
Creator
模式的应用例
为了更清楚地说明
Creator
模式，我们
举一个
GUI
的例子：
有一个用户窗口
MainWindow
，包含
Menu
，
ToolBar
< br>，
Dialog
等，
Dialo
g
上布置有
Textbox
，
Button
等元素。
我们应用
Creator
模式，先为它们设计好具有阶层关系
的类图，如下：
因为
MyMenu
，
MyToolBar
，
MyDialog
由
Mai
nWindow
所包含，
MyTextbox
< br>，
MyButton
被
MyDi
alog
包含，
MainWindow
由
Main
类调用。
根据
Creator
模式所提倡的方法，它们的实例的
创建职责的分配应该是：
MainWindow
的实例由
Main
创建；
MyMenu
，
MyToolbar<
/p>
，
MyDialog
的实例由
MainWindow
创建；
< br>MyTextbox
，
MyButton
的实例由
MyDialog
创建。
反过来，如果
MyMenu<
/p>
，
MyToolBar
，
MyDialog
等实例的创建都放在
Main
类里，那么
Main
就跟它们产生一种“关联
”关系，如果
MyMenu
，
MyToolBar
，
MyDialog
等发生修改，
Main
也不得不跟着一起修
改，也就是说大大增强了
Main
类跟它们之间的耦合关系；而
Main
类
本身，也聚集了多余的实例创建功能，降低了
Main
类的聚合
性。
GRASP High Cohesion Pattern -
GRASP
之高内聚模式
高内聚模式（
High
Cohesi
on
）是
GRASP
模式中为降低类的
复杂程度，简化控制而提出的面
向对象设计的原则性模式。
高内
聚
（
High Cohesion
）<
/p>
与低耦合
（
Low Coupling<
/p>
）
模式是
GRASP
其他模式的根本。
问题
怎么做才能降低类的复杂程度，简化控制？
High
Cohesion
模式所提倡的解决方案
紧密相关的功能（职责）应该分配给同一个类。
所谓内聚，是指单个物体（类）内部的功能聚集度。比如，只
包含有相互关联的功能的类，
具有高内聚性，同时，它的外部表现（作用，意图）也就明
显；反之，如果一个类由一些不
相关的功能构成，
它的内聚性就
低，
它的外部表现就不明显，
一方面很难理解它的作用和意
图，另一方面，一旦需求变化
,
扩展性就差
。
在现实世界里，高内聚（
High Cohesion
）表现在“各司其职”上，也就是说自己只干跟自己
相关的工作，
别人的工作让别人做。
比如，
电视机只有信息
传播的功能，
冰箱只有冷藏冷冻
的功能，
它们就是一个功能高内聚的个体。
为什么不把电视机与冰箱的功能做在一起呢？因
为做在一起的话，
一方面，
只需要电视或冰
箱功能的消费者却不得不同时购买它们的整合体，
而且消费者如果想换代电视机时，
冰箱也只有一起换代；
另一方面，
如果厂家
需要升级电视
功能，
也不得不考虑怎么整合原来的冰箱功能。<
/p>
也就是说功能低内聚的产品，
不利于消费者
使用，不利于生产者维护，不利于产品本身的升级换代。
同样，反映到软件设计上，低内聚的类存在使用难，维护升级难的缺点。
高内聚
（
High Cohesion
）
与低耦合
（
Low Coupling
）
是
GRA
SP
模式的核心概念，
是其它
GRAS
P
模式的根本。
< br>优秀的面向对象设计，一般都遵从
[
高内聚，低耦合
]
原则。
应用
High
Cohesion
模式的好处
-
-
聚集相关功能，结构清晰，容易理解
只聚集相关功能，使得类的职责单一明确，从而降低类的复杂程度，使用简单
GRASP Low Coupling
Pattern - GRASP
之低耦合模式
低耦合模式（
Low Coupling
）是
GRASP
模式中为降低类之间的关联程度，适应可变性
而提出
的面向对象设计的原则性模式。高内聚（
High
Cohesion
）与低耦合（
Low
Coupling
）模式是
GRASP
其他模式的根本。
问题
怎么做才能降低类之间关联程度，能适应需求的变化呢？
Low
Coupling
模式所提倡的解决方案
为类分配职责时，应该尽量降低类之间的关联关系（耦合性）
。亦即，应该以降低类
之间的
耦合关系作为职责分配的原则。
所谓耦合，是指多个物体（类）之间的物理或者意思上的关联
程度。在面向对象方法中，类
是最基本的元素，
耦合主要指不同
类之间相互关联的紧密程度。
面向对象里的关联，
主要指
一个类对另一个类的调用，聚合（包含）
，参数传递等关系。
比如，所谓
2
个关联得非常紧密的类（高耦合）
，是指其中一个类发生变化（修改
）时，另
一个类也不得不跟着发生变化（修改）
。
面向对象设计要求类之间满足
< br>“低耦合”
原则，
它是衡量一个设计是否优良的一个重要
标准，
因为“低耦合”有助于使得系统中某一部分的变化对其它部分的影响降到最低程度
。
应用
High
Cohesion
模式的好处
-
-
高内聚
（
High Cohesion
）
与低耦合
（
Low Coupling
）
是
GRA
SP
模式的核心概念，
是其它
GRAS
P
模式的根本。
< br>优秀的面向对象设计，一般都遵从
[
高内聚，低耦合
]
原则。
独立性，有利于重用。
适应需求变化，一旦发生变化时，可以把影响缩小到最小范围。
内聚与耦合的辩证关系
1
，
一方面
，高内聚要求把紧密关联的功能（职责）聚集在同一个类中，防止功能的扩散和
类的无谓
增加，从而减少类之间的关联，降低类之间的发生耦合的机率。
2
，
另一方
面，高内聚要求把不相关的功能分散到不同的类，类增加了，势必造成相互关联
类的增加
，从而增大类之间发生耦合的机率。
面向对象设计，应该考虑
效率，实现难度等因素，同时兼顾高内聚（
High
Cohesion
）与低耦
合（
Low
Coupling
）性。
-
-
-
-
-
-
-
-
-
上一篇：英语畅谈中国文化(1)
下一篇：网页HTML中各个代码意思大全