1)每个类大约有3-5个职责.
?? 一般来说,类应该尽可能保持简单.这通常限制类能够支持的3-5个职责的数目.
2)不存在独立的类.
好的OO分析和设计的精华是,类相互协作使用户受益.同样,每个类应该同少量的类协作以提供所有的期望的功能.类可以把他们的一些职责托付给专注于特定功能的其他辅助类.
3)当心一些非常小的类.
有时候很难取得正确的平衡.如果模型看起来有大量的非常小的类,每个类都只有一个或者两个职责,那么你应该仔细察看以把这些小的类整合成一个更大的类.
4)当心几个非常庞大的类
?上述的反面是,模型具有很少的类,但是每个类具有大量的(大于5个)的职责.解决问题的策略是一次察看这些类.看是否每个类都能够被分解成为两个或者多个能够承担恰当数目职责的更小的类.
5)当心”伪类”
伪类其实是一般过程的函数,它伪装成类.Grady Booch讲了一个奇闻轶事,一个非常简单的系统却又成千上万个类.仔细审查,每个类都有一个命名为Dolt()(傻瓜)的操作,当分析师习惯于自顶向下的功能分解的技术,第一次处理OO分析设计时,伪类对他来说总是很危险的.
6)当心”万能类”
存在似乎能够承担任何工作的类.看看名称为System和Controller的类,处理这个问题的策略是看看万能类的职责分解未内聚的子集.如果能,这些内聚职责的每一个集合可以分离成独立的类.这些更小的类进行协作以实现由原来万能类所提供的行为.
7)避免深度继承树
设计良好的继承层次的本质是继承层次中每个凑次昂层次应该具有良好定义的目的.容易添加很多实际上却不能服务于任何目的的层次.实际上常犯的错误是使用继承来实现一种功能分解,其中每个抽象层次恰好有一个职责.无论从哪个方面来讲,这都是无意义的,会导致复杂的难以理解的模型,分析中,继承仅用于存在直接产生于问题域的,清晰的,显而易见的继承层次的场合.
摘自于<<UML和统一过程使用面向读一项的分析和设计>>一书P108页
