（1）一切数据都应该隐藏在所在的类的内部。
??）类的运用者必须依赖类的共有接口， 但类不能依赖它的运用者。
??）尽量减少类的协议中的消息。
??）完成一切类都了解的最基本私有接口[例如， 拷贝操作（深拷贝和浅拷贝）、相等性判断、正确输出内容、从ASCII描绘解析等等].
??）不要把完成细节（例如放置共用代码的私有函数）放到类的私有接口中。
如果类的两个方法有一段公共代码， 那么就可以创立一个防止这些公共代码的私有函数。
??）不要以用户无法运用或不感兴趣的东西扰乱类的私有接口。
??）类之间应该零耦合， 或者只有导出耦合关系。 也即， 一个类要么同另一个类毫有关系， 要么只运用另一个类的私有接口中的操作。
??）类应该只表示一个关键笼统。
包中的一切类对于同一类性质的变化应该是共同封闭的。 一个变化若对一个包影响， 则将对包中的一切类发生影响， 而对其他的包不造成任何影响 . （9）把相关的数据和行为集中放置。
设计者应当留意那些经过get之类操作从别的对象中获取数据的对象。 这种类型的行为暗示着这条经验原则被违犯了。
??0）把不相关的信息放在另一个类中（也即：互不沟通的行为）。
朝着稳定的方向停止依赖。
??1）确保你为之建模的笼统概念是类， 而不只是对象扮演的角色。 类应当一致地共享工作。
??3）在你的系统中不要创立全能类/对象。 对名字包含Driver、Manager、System、Susystem的类要特别多加小心。
规划一个接口而不是完成一个接口。
??4）对公共接口中定义了少量访问方法的类多加小心。 少量访问方法意味着相关数据和行为没有集中存放。
??5）对包含太多互不沟通的行为的类多加小心。
这个效果的另一表现是在你的应用顺序中的类的私有接口中创立了很多的get和set函数。
??6）在由同用户界面交互的Java面向对象模型构成的应用顺序中， 模型不应该依赖于界面， 界面则应当依赖于模型。
??7）尽能够地按照理想世界建模（我们经常为了遵守系统功能分布原则、防止全能类原则以及集中放置相关数据和行为的原则而违犯这条原则） . （18）从你的设计中去除不需要的类。
一般来说， 我们会把这个类升级成一个属性。
??9）去除系统外的类。
系统外的类的特点是， 笼统地看它们只往系统范围发送消息但并不接受系统范围内其他类收回的消息。
??0）不要把操作变成类。 质疑任何名字是动词或者派生自动词的类， 特别是只有一个有意义行为的类。 思索一下那个有意义的行为能否应当迁移到曾经存在或者尚未发现的某个类中。
??1）我们在创立应用顺序的分析模型时经常引入代理类。 在设计阶段， 我们常会发现很多代理没有用的， 应当去除。
??2）尽量减少类的协作者的数量。
一个类用到的其他类的数目应当尽量少。
??3）尽量减少类和协作者之间传递的消息的数量。
??4）尽量减少类和协作者之间的协作量， 也即：减少类和协作者之间传递的不同消息的数量。
??5）尽量减少类的扇出， 也即：减少类定义的消息数和发送的消息数的乘积。
??6）如果类包含另一个类的对象， 那么包含类应当给被包含的对象发送消息。 也即：包含关系总是意味着运用关系。
??7）类中定义的大少数方法都应当在大少数时间里运用大少数数据成员。
??8）类包含的对象数目不应当超越开发者短期记忆的容量。 这个数目经常是6. 当类包含多于6个数据成员时， 可以把逻辑相关的数据成员划分为一组， 然后用一个新的包含类去包含这一组成员。
??9）让系统功能在窄而深的继承体系中垂直分布。
??0）在完成语义约束时， 最好依据类定义来完成。 这经常会导致类泛滥成灾， 在这种状况下， 约束应当在类的行为中完成， 通常是在结构函数中完成，但不是必须如此。文章由
太空记忆枕整理，收集辛苦，希望能保留出处。
