第八章 OOD评判标准
一、什么是评判标准？为什么需要是评判标准？
追求一个好的设计，以及设计完成后评价它是不是好的
设计，不是一个笼统的概念,而是有一些具体的评判
标准（ criteria ）。
正确的设计是不是唯一的；
大系统经常面临多种方案的选择，各种方案有好坏之分
方法并没有提供全部细节和具体答案，
需要有一些准则来控制设计质量
二、耦合 Coupling—— 连接、结合、联系、并联
这里指 OOD片段之间的相互联系
考虑耦合问题的目的：
改动一部分，对其它部分影响最小
阅读一部分，查阅其它部分较小
耦合强度的衡量
成分之间的信息传输量
成分之间的信息复杂程度
1、交互耦合 Interaction Coupling (低耦合为好 )
OOD中的交互耦合 —— 消息连接
（ 1）一条消息中的参数数目
一条消息中参数应尽量不超过 3个
3个以上的参数属于高度耦合 (强耦合 )，容易有波动效应
—— 简化
（ 2）减少一个对象发出和接收消息的数目
如果一个对象进出消息连接太多，则属强耦合
P A Q
（ 3）消息穿越：
对象 A从 P接收消息，如果不使用它的任何信息，也不执行什么活
动，只是转送给 Q，则叫消息穿越，应该加以修改。
2.继承耦合 Inheritance Coupling (强耦合为好 )
继承耦合 ? 一般 -特殊关系
继承耦合是 OOA和 OOD努力追求的目标
避免以下两种低耦合
（ 1）特殊类拒绝一般类的许多属性和服务 (如图
8.3.1(a))
（ 2）继承而不使用
拒绝的情况可通过 OOD模型看出，
不使用的情况要通过类定义模板审查出来。
修改：
重新组织类，调整结构
三、内聚 Cohesion (高内聚为好 )
人：一个组织内部，人与人之间关系紧密程度
OOD：一个 OOD成分内部元素的关系紧密程度
1、服务内聚
高内聚：一个服完成一个功能
低内聚：
一个服务实现多项功能，或者只实现功能的一部分
判断方法：
服务的大小
用简单的句子描述
2、类内聚
指属性和服务应该是高内聚的
没有多余的属性和服务 —— 都是描述对象本身责任的
3.一般 -特殊内聚
特殊类应该真正地描述了一般类的特化
概念上要讲得通 (包括命名 )
确实继承了一般类的许多属性和服务
五、其它评判标准
1,设计的清晰度
使设计能看得懂, 读得通 —— 象读一篇陈述文
对实现, 维护十分重要
主要因素：
① 使用一致的词汇表
② 遵循已有的协议
③ 消息模板要少
④ 明确定义类的职责 —— 由类名确切地表达出来
四、复用（略）
2、一般 -特殊结构的深度
中等规模的系统 (100个类 )—— 不超过 7± 2层
不要搞得继承层次太深
不要为提炼而提炼
3.保持对象和类的简单性
在任何方法中，简单性都是一种美德！
保持对象和类的简单，
保持消息协议简单
保持服务简单
有以下的准则
①避免太多的属性
无用的绝对不设 —— 运用抽象原则
有用但太多 —— 寻找结构
②瞄准责任
避免模糊的类定义
判断：用一两句话描述这个类，
不能用“有时”、“有点”、“如同”等词
汇
③对象之间的合作最小化
3-5个合作者 —— 为了保持简单、清晰
④避免一个对象中太多的服务
公共服务 —— 少于 7± 2个；私有 —— 若干
4、保持协议的简单
消息协议 —— 参数 ≤ 3
避免“协议隐语”
—— 例如，使用没有字面意义的参数名,x,y,a1,a2等等
5、保持服务简单
每个服务的代码不要太多
避免在一个服务中完成多项功能
6.设计易变性的最小化
观察改动 (需求错误 )时影响范圆有多大。
应该有随时间下降的曲线
7.系统总体规模最小化
追求小规模 —— 小系统为了清晰, 大系统为了生存
大小取决于问题, 也取决于人
笨的方法是使系统规模膨胀的根源
数据结构与算法相比, 前者影响更大
8.能用脚本（ scenario）评估
由人 (复审员 )按照脚本 (OOD文档 )来“走通”一个设计
由人模拟对象
作用：
检查设计的正确性
发现更好的方法来改进设计
9,通过, 关键成功因素, 来评估
关键成功因素有：可重用性, 可读性, 性能
10,公认的优雅 （ Elegance） 风格
优雅一词, 最难把握, 各见仁智
但也有些公认的东西
反复出现的模式
反映专门知识的设计成分
设计中的, 块, 与问题域中的, 块, 对应得好
六、小结
为了迁就实际条件，往往在设计质量上作出让步
以前让步，现在未必
尽量少作让步
高质量的设计表明你的成就
一、什么是评判标准？为什么需要是评判标准？
追求一个好的设计，以及设计完成后评价它是不是好的
设计，不是一个笼统的概念,而是有一些具体的评判
标准（ criteria ）。
正确的设计是不是唯一的；
大系统经常面临多种方案的选择，各种方案有好坏之分
方法并没有提供全部细节和具体答案，
需要有一些准则来控制设计质量
二、耦合 Coupling—— 连接、结合、联系、并联
这里指 OOD片段之间的相互联系
考虑耦合问题的目的：
改动一部分，对其它部分影响最小
阅读一部分，查阅其它部分较小
耦合强度的衡量
成分之间的信息传输量
成分之间的信息复杂程度
1、交互耦合 Interaction Coupling (低耦合为好 )
OOD中的交互耦合 —— 消息连接
（ 1）一条消息中的参数数目
一条消息中参数应尽量不超过 3个
3个以上的参数属于高度耦合 (强耦合 )，容易有波动效应
—— 简化
（ 2）减少一个对象发出和接收消息的数目
如果一个对象进出消息连接太多，则属强耦合
P A Q
（ 3）消息穿越：
对象 A从 P接收消息，如果不使用它的任何信息，也不执行什么活
动，只是转送给 Q，则叫消息穿越，应该加以修改。
2.继承耦合 Inheritance Coupling (强耦合为好 )
继承耦合 ? 一般 -特殊关系
继承耦合是 OOA和 OOD努力追求的目标
避免以下两种低耦合
（ 1）特殊类拒绝一般类的许多属性和服务 (如图
8.3.1(a))
（ 2）继承而不使用
拒绝的情况可通过 OOD模型看出，
不使用的情况要通过类定义模板审查出来。
修改：
重新组织类，调整结构
三、内聚 Cohesion (高内聚为好 )
人：一个组织内部，人与人之间关系紧密程度
OOD：一个 OOD成分内部元素的关系紧密程度
1、服务内聚
高内聚：一个服完成一个功能
低内聚：
一个服务实现多项功能，或者只实现功能的一部分
判断方法：
服务的大小
用简单的句子描述
2、类内聚
指属性和服务应该是高内聚的
没有多余的属性和服务 —— 都是描述对象本身责任的
3.一般 -特殊内聚
特殊类应该真正地描述了一般类的特化
概念上要讲得通 (包括命名 )
确实继承了一般类的许多属性和服务
五、其它评判标准
1,设计的清晰度
使设计能看得懂, 读得通 —— 象读一篇陈述文
对实现, 维护十分重要
主要因素：
① 使用一致的词汇表
② 遵循已有的协议
③ 消息模板要少
④ 明确定义类的职责 —— 由类名确切地表达出来
四、复用（略）
2、一般 -特殊结构的深度
中等规模的系统 (100个类 )—— 不超过 7± 2层
不要搞得继承层次太深
不要为提炼而提炼
3.保持对象和类的简单性
在任何方法中，简单性都是一种美德！
保持对象和类的简单，
保持消息协议简单
保持服务简单
有以下的准则
①避免太多的属性
无用的绝对不设 —— 运用抽象原则
有用但太多 —— 寻找结构
②瞄准责任
避免模糊的类定义
判断：用一两句话描述这个类，
不能用“有时”、“有点”、“如同”等词
汇
③对象之间的合作最小化
3-5个合作者 —— 为了保持简单、清晰
④避免一个对象中太多的服务
公共服务 —— 少于 7± 2个；私有 —— 若干
4、保持协议的简单
消息协议 —— 参数 ≤ 3
避免“协议隐语”
—— 例如，使用没有字面意义的参数名,x,y,a1,a2等等
5、保持服务简单
每个服务的代码不要太多
避免在一个服务中完成多项功能
6.设计易变性的最小化
观察改动 (需求错误 )时影响范圆有多大。
应该有随时间下降的曲线
7.系统总体规模最小化
追求小规模 —— 小系统为了清晰, 大系统为了生存
大小取决于问题, 也取决于人
笨的方法是使系统规模膨胀的根源
数据结构与算法相比, 前者影响更大
8.能用脚本（ scenario）评估
由人 (复审员 )按照脚本 (OOD文档 )来“走通”一个设计
由人模拟对象
作用：
检查设计的正确性
发现更好的方法来改进设计
9,通过, 关键成功因素, 来评估
关键成功因素有：可重用性, 可读性, 性能
10,公认的优雅 （ Elegance） 风格
优雅一词, 最难把握, 各见仁智
但也有些公认的东西
反复出现的模式
反映专门知识的设计成分
设计中的, 块, 与问题域中的, 块, 对应得好
六、小结
为了迁就实际条件，往往在设计质量上作出让步
以前让步，现在未必
尽量少作让步
高质量的设计表明你的成就
