你不必严酷遵守这些原则，违反它们也不会被处以宗教科罚。但你理当把这些原则算作警铃，若违反了其中的一条，那么警铃就会响起 。 ----- Arthur J.Riel

(1)所稀有据都应该潜匿在地址的类的内部。

(2)类的使用者必需依靠类的共有接口，但类不能依靠它的使用者。

(3)尽量削减类的和谈中的动静。

(4)实现所有类都理解的最根基公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判定、正确输出内容、年夜ASCII描述解析等等]。

(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。

如不美观类的两个体例有一段公共代码，那么就可以建树一个防止这些公共代码的私有函数。

(6)不要以用户无法使用或不感乐趣的工具侵扰类的公有接口。

(7)类之间应该疗揭捉合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。

(8)类应该只暗示一个关头抽象。

包中的所有类对于统一类性质的转变应该是配合封锁的。一个转变若对一个包影响，则将对包中的所有类发生影响，而对其他的包不　　造成任何影响 .

(9)把相关的数据和行为集中放置。

设计者理当寄望那些经由过程get之类操作年夜此外对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。

(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。

朝着不变的标的目的进行依靠.

(11)确保你为之建模的抽象概念是类，而不只是对象饰演的脚色。

(12)在水平标的目的上尽可能统一地分布系统功能，也即：按照设计，顶层类理当统一地共享工作。

(13)在你的系统中不要建树万能类/对象。对名字包含Driver、Manager、System、Susystem的类要出格多加小心。

规齐截个接口而不是实现一个接口。

(14)对公共接口中界说了年夜量访谒体例的类多加小心。年夜量访谒体例意味着相关数据和行为没有集中存放。

(15)对包含太多互不沟通的行为的类多加小心。

这个问题的另一默示是在你的应用轨范中的类的公有接口中建树了良多的get和set函数。

(16)在由同用户界面交互的面向对象模子组成的应用轨范中，模子不应该依靠于界面，界面则理当依靠于模子。

(17)尽可能地按照现实世界建模(我们经常为了遵守系统功能分布原则、避免万能类原则以及集中放置相关数据和行为的原则而违反这条原则) 。

(18)年夜你的设计中去除不需要的类。

一般来说，我们会把这个类降级成一个属性。

(19)去除系统外的类。

系统外的类的特点是，抽象地看它们只往辖档挽域发送动静但并不接管辖档挽域内其他类发出的动静。

(20)不要把操作酿成类。质疑任何名字是动词或者派生自动辞书类，出格是只有一个有意义行为的类。考虑一下阿谁有意义的行为是否理当迁移到已经存在或者尚未发现的某个类中。

(21)我们在建树应用轨范的剖析模子时经常惹人代办代庖类。在设计阶段，我们常会发现良多代办代庖没有用的，理当去除。

(22)尽量削减类的协作者的数目。

一个类用到的其他类的数目理当尽量少。

(23)尽量削减类和协作者之间传递的动静的数目。

(24)尽量削减类和协作者之间的协作量，也即：削减类和协作者之间传递的分歧动静的数目。

(25)尽量削减类的扇出，也即：削减类界说的动静数和发送的动静数的乘积。

(26)如不美观类包含另一个类的对象，那么包含类理当给被包含的对象发送动静。也即：包含关系老是意味着使用关系。

(27)类中界说的年夜年夜都体例都理当在年夜年夜都时刻里使用年夜年夜都数据成员。

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

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

(29)让系统功能在窄而深的担任系统中垂直分布。

(30)在实现语义约束时，最好按照类界说来实现。这经常会导致类泛滥成灾，在这种情形下，约束理当在类的行为中实现，凡是是在机关函数中实现，但不是必需如斯。

(31)在类的机关函数中实现语义约束时，把约束测试放在机关函数规模所许可的尽量深的包含条理中。

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

(33)约束所依靠的语义信息如不美观很少改变，那么最好分布在约束所涉及的各个类中。(责任编辑：admin)