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