|
(1)所有数据都应该隐藏在所在的类的内部。 (2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。 (3)尽量减少类的协议中的消息。 (4)实现所有类都理解的最基本公有接口。 (5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。 (6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。 (7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。 (8)类应该只表示一个关键抽象。 (9)把相关的数据和行为集中放置。 (10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。 (11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。 (12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。 (13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。规划一个接口而不是实现一个接口。 (14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。 (15)对包含太多互不沟通的行为的类多加小心。 (16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。 (17)尽可能地按照现实世界建模。 (18)从你的设计中去除不需要的类。 (19)去除系统外的类。 (20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。 (21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。 (22)尽量减少类的协作者的数量。 (23)尽量减少类和协作者之间传递的消息的数量。 (24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。 (25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。 (26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。 (27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。 (28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。 (29)让系统功能在窄而深的继承体系中垂直分布。 (30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。 (31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。 (32)约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。 (33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。 (34)类必须知道它包含什么，但是不能知道谁包含它。 (35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。 (36)继承只应被用来为特化层次结构建模。 (37)派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。 (38)基类中的所有数据都应当是私有的，不要使用保护数据。 (39)在理论上，继承层次体系应当深一点，越深越好。 (40)在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。 (41)所有的抽象类都应当是基类。 (42)所有的基类都应当是抽象类。 (43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。 (44)如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。 (45)如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。 |
