检查点:设计类
主题
- 类名明确反映它所扮演的角色。
- 类的描述明确传达类的目的。
- 类代表一个定义良好的抽象。
- 类的属性和操作对于履行类的职责都是最根本的。
- 每个类表示一小组一致且唯一的职责。
- 类的职责是定义良好、明确陈述的,并与类的目的明确相关。
- 每个类是相对自我包含的,并与其它类松耦合。
- 类的职责的抽象级别一致(即,高级(应用级别)和低级(实施级别)职责不是混在一起的)。
- 在同一继承层次结构中的类拥有唯一的类属性、操作和关系(即,它们继承所有公共的属性、操作和关系)。
- 说明了类实例的完整生命周期。每个对象由一个或多个用例实现创建、使用或除去。
- 类满足了由用例实现建立的行为需求。
- 满足了需求规范中的类的所有需求。
- 类的需求(如类描述和序列图的对象所反映)与类的状态机一致。
- 类的所有职责是相关的,这样,类要存在于系统中,就不可能使用它的某些职责,而不使用它的其它职责。
- 没有两个类在本质上有相同的目的。
- 泛化关系层次结构是平衡的,因此不存在层次结构非常扁平或非常深的类。
- 明显的共性反映在继承层次结构中。
- 没有任何超类看上去是子类属性的合并。
- 继承层次结构中没有具有不相关的属性的中间抽象类,示例包括继承树两边的重复子类。
- 继承用于捕获公共设计抽象,而不主要用于实施考虑事项(即:复用代码位或类结构)。
- 类名指示目的。
- 类名遵循在项目设计指南中指定的命名约定。
- 每个操作名都是描述性的和可理解的。
- 状态机和操作是一致的。
- 状态机和操作完整地描述类的行为。
- 每个操作的参数在数量、名称和类型方面都是正确的。
- 定义的每个操作的实施规范都是正确的。
- 操作特征符符合目标编程语言的标准。
- 每个操作至少由一个用例实现使用。
- 需要类的所有关系来支持类的某个操作。
- 每个属性表示一个概念上的含义。
- 每个属性名都是描述性的并正确传达它存储的信息。
- 聚集和关联的角色名描述关联和被关联的类之间的关系。
- 关系的多重性是正确的。
- 状态机尽可能简单,但仍能表达必需的行为。
- 状态机不包含任何多余的状态或转移。
- 状态机具有明确的环境。
- 所有引用的对象对包含它的对象都是可见的。
- 状态机是高效的,并在时间和资源最佳平衡(由它分派的操作定义)的条件下执行它的行为。
- 状态机是可理解的。
- 状态和转移名称在系统领域环境中是可理解的。
- 状态名称表明正在等待或发生什么,而不是已经发生了什么。
- 状态和转移名称在状态机中是唯一的(虽然不是严格的要求,但在调试中它有助于实施唯一名称)。
- 状态的逻辑分组包含在组合状态中。
- 组合状态用于有效减少复杂度了吗?
- 转移标注反映转移的底层原因。
- 关于状态转移的代码片段,其详细代码不会超过 25 行;相反地,有效地使用函数来减少转移代码复杂度。
- 已检查状态机嵌套,确保嵌套深度不会太深而不可理解;对于大多数复杂行为,一级或两级子状态通常就足够了。
- 已用活动类代替了并发子状态;活动类几乎总是比并发子状态更好的备选方案并更易理解。
- 已说明了错误或维护状态。
- 在扩展的状态变量的位置已使用了子状态;转移警戒条件测试几个变量来确定转移应出现的状态是没有根据的。
- 状态机不同于流程图。
- 状态机不是过度分解的,它由带单个子状态的嵌套的状态机组成。
在嵌套的子状态是占位符(用于未来的设计工作或划分子类)的情况下,倘若选择是有意的,这可能暂时可被接受。
| |
|