消息数的乘积。

 

(26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。

 

(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。

 

(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。

 

当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。

 

(29)让系统功能在窄而深的继承体系中垂直分布。

 

(30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在　　构造函数中实现，但不是必须如此。

 

(31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。

 

(32)约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。

 

(33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。

 

(34)类必须知道它包含什么，但是不能知道谁包含它。

 

(35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。

 

(36)继承只应被用来为特化层次结构建模。

 

(37)派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。

 

(38)基类中的所有数据都应当是私有的，不要使用保护数据。

 

类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。

 

(39)在理论上，继承层次体系应当深一点，越深越好。

 

(40)在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。

 

(41)所有的抽象类都应当是基类。

 

(42)所有的基类都应当是抽象类。

 

(43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。

 

(44)如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。

 

(45)如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。

 

(46)如果两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们需要被多态地使用时，他们才应当从一个公共基类　　继承。

 

(47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。

 

(48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。

 

(49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。

 

(50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。

 

(51)如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。

 

(52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。

 

(53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。

 

(54)在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。

 

(55)如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法