（1）所有数据都应该隐藏在所在的类的内部。.doc

（1）所有数据都应该隐藏在所在的类的内部。.doc（1） 所有数据都应该隐藏在所在的类的内部。
（2） 类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。
（3） 尽量减少类的协议屮的消息。
（4） 实现所有类都理解的最基本公有接口 ［例如，拷贝操作（深拷贝和浅拷 贝）、相等性判断、正确输出内容、从ASCII描述解析等等］.
（5） 不要把实现细节（例如放置共用代码的私有函数）放到类的公有接口 中。
如果类的两个方法有一段公共代码，那么就可以创建-•个防止这些公共代码 的私有函数。
（6） 不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。
（7） 类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另 一个类毫无关系，要么只使用另一个类的公有接口屮的操作。
（8） 类应该只表示一个关键抽象。
包屮的所有类对于同一类性质的变化应该是共同封闭的。一 •个变化若对一 •个 包影响，则将对包屮的所有类产生影响，而对其他的包不造成任何影响• （9） 把相关的数据和行为集屮放置。
设计者应当留意那些通过get之类操作从别的对象屮获取数据的对象。这种 类型的行为暗示着这条经验原则被违反了。
（10） 把不相关的信息放在另一个类屮（也即：互不沟通的行为）。
朝着稳定的方向进行依赖。
（11） 确保你为Z建模的抽象概念是类，血不只是对象扮演的角色。类应当 统一地共亨工作。
（13） 在你的系统屮不要创建全能类/对象。对名字包含Driver> Manager> System、Susystem的类要特别多加小心。
规划一个接口而不是实现一个接口。
（14） 对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味 着和关数据和行为没有集屮存放。
（15）对包含太多互不沟通的行为的类多加小心。
这个问题的另一表现是在你的应用程序屮的类的公有接口屮创建了很多的 get和set函数。
（16） 在由同用户界面交互的血空面向对象模型构成的应用程序屮，模型 不应该依赖于界面，界面则应当依赖于模型。
（17） 尽可能地按照现实世界建模（我们常常为了遵守系统功能分布原则、 避免全能类原则以及集屮放置相关数据和行为的原则血违背这条原则）・（18） 从你的设计屮去除不需要的类。
一般来说，我们会把这个类降级成-个属性。
（19） 去除系统外的类。
系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统 领域内其他类发出的消息。
（20） 不要把操作变成类。质疑任何名字是动词或者派生口动词的类，特别 是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存 在或者尚未发现的某个类屮。
（21） 我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我 们常会发现很多代理没有用的，应当去除。
（22） 尽量减少类的协作者的数量。
一个类用到的其他类的数H应肖尽量少。
（23） 尽量减少类和协作者之间传递的消息的数量。
（24） 尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递 的不同消息的数量。
（25） 尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘 积。
（26） 如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消 息。也即：包含关系总是意味着使用关系。
（27） 类小定义的大多数方法都