（2）类的用户必须依赖于类的公共接口，但类不能依赖于它的用户。
（3）最小化类协议中的消息。
（4）实现所有类都理解的最基本的公共接口。例如，复制操作（深拷贝和浅拷贝）、相等判断、正确输出内容、ASCII描述分析等。
（5）不要将实现细节（如公共代码的私有函数）放入类的公共接口中。
如果类的两个方法有一段公共代码，则可以创建阻止这些公共代码的私有函数。
（6）不要因用户不能使用或不感兴趣而干扰类的公共接口。
（7）类之间应该是零耦合，或者只有派生的耦合关系，也就是说，一个类可以与另一个类无关，或者只在另一个类的公共接口中使用该操作。
（8）类应该只表示一个关键抽象。
一个包中的所有类都应该在同一类属性上合在一起。如果一个更改影响包，它将对包中的所有类产生影响，并且不会对其他包产生任何影响。
（9）相关数据和行为的集中化。
设计者应该注意那些通过诸如get这样的操作从其他对象获取数据的对象。
（10）把不相关的信息放在另一个类中（即不相互交流的行为）。
依靠稳定的方向。
（11）确保所建模的抽象概念是一个类，而不仅仅是对象的角色。
（12）系统的功能在水平方向上尽可能统一，即按照设计的要求，最高阶层要统一工作。
（13）不创造全能的类/对象在您的系统。小心类的名字包括司机、经理、系统、和Susystem。
规划接口而不是接口。
（14）对于在公共接口中定义大量访问方法的类要更加小心，大量的访问方法意味着相关数据和行为不以集中方式存储。
（15）对于那些包含太多不沟通的课程要更加小心。
这个问题的另一个表现是在应用程序中的类的公共接口中创建许多get和Set函数。
（16）在由与用户接口交互的面向对象模型组成的应用程序中，模型不应该依赖于接口，而接口应该依赖于模型。
（17）尽可能根据现实世界进行建模。我们经常违反这一原则，以遵循系统功能分配原则，避免万能原则，集中放置相关数据和行为。
（18）从设计中删除不需要的类。
一般来说，我们会把这类为一个属性。
（19）移除系统之外的类。
系统外部的类以抽象视图为特征，它们只向系统域发送消息，但不接受系统域中其他类发送的消息。
（20）不要把操作变成一个类，将任何名称作为动词或派生的自动词提问，特别是只有一个有意义的行为。考虑是否有意义的行为应该被移到已经存在或未被发现的类中。
（21）我们在创建应用程序的分析模型时经常引入一个代理类，在设计阶段，我们经常发现许多代理不使用它，应该被删除。
（22）尽可能减少班级合作者的数量。
类使用的其他类的数量应该尽可能的小。
（23）最小化类与合作作者之间传递的消息数量。
（24）尽量减少类与合作作者之间的协作量，也就是减少类和关联的联合作者之间传递的不同消息的数量。
（25）最小化类的扇出，即消息数量和类定义发送的消息数的乘积。
（26）如果类包含另一个类的对象，则包含类应该向包含的对象发送消息。
（27）类中定义的大多数方法应该在大多数时间内使用大多数数据成员。
（28）类所包含的对象数量不应超过开发人员短期内存的容量，这个数字通常是6。
当一个类包含超过6个数据成员时，逻辑相关的数据成员可以被划分为一个集合，然后包含一个新的包含类来包含组成员。
（29）让系统功能在一个窄而深的继承系统中垂直分布。
（30）当语义约束被实现时，最好根据类定义实现它，这常常导致类的溢出。在这种情况下，约束应该在类行为中实现，通常在构造函数中实现，但不一定。
（31）当在类构造函数中实现语义约束时，约束测试被放置在构造函数域中的包容层次结构的深度中。
（32）如果约束所依赖的语义信息经常被改变，最好放在一个集中的第三方对象中。
（33）如果约束所依赖的语义信息很少改变，最好在约束中涉及的各个类中进行分配。
（34）类必须知道它包含什么，但是它不知道谁包含它。
（35）共享文本范围（也包括在同一个类中）的共享应该不具有相互之间的使用关系。
（36）继承只应用于对特定的层次结构进行建模。
（37）派生类必须知道基类，而基类不应该知道它们派生类的任何信息。
（38）基类中的所有数据应该是私有的，不使用保护数据。
类的设计者不应该将类用户不需要的任何东西放在公共接口中。
（39）从理论上讲，继承的层次应该更深一点，越深入越好。
（40）在实践中，等级制度的深度不应超过一个普通人的短期记忆能力，广泛接受的深度值是6。
（41）所有抽象类都应该是基类。
（42）所有基类都应该是抽象类。
（43）将数据、行为、和/或接口的通用性放入继承层次结构的高层中。
（44）如果两个或多个类共享公共数据（但没有公共行为），我们应该将公共数据放在一个类中，并且共享这个数据的每个类都包含这个类。
（45）如果两个或多个类具有公共数据和行为（即方法），则这些类中的每一个都应该从表示这些数据和方法的公共基类继承。
（46）如果两个或多个类共享公共接口（指消息而不是方法），则只有当它们需要具有多态性时，它们才继承来自公共基类。
（47）对对象类型显示的分析通常是错误的，在大多数情况下，设计者应该使用多态性。
（48）对属性值的显示的分析常常是错误的，应该解耦一个类来合成继承层次结构，并将每个属性值转换为派生类。
（49）不要通过继承关系来对类的动态语义进行建模，试图使用静态语义关系进行动态语义建模会导致运行时的切换类型。
（50）不要把类的对象变成派生类。
（51）如果您认为您需要在运行时创建一个新类，那么退后一步，看看您创建的对象是什么。
（52）在派生类中使用空方法（这是无关的）来重写基类中的方法是非法的。
（53）不要把可选的包含与继承的需要混淆起来。建模可选的继承作为继承将导致泛型类。
（54）在创建继承层次结构时，尽量创建可重用框架，而不是可重用组件。
（55）如果你在设计中使用多重继承，假设你先犯了错误，如果你不犯错误，你就得试着去证明它。
（56）只要我们在面向对象的设计中使用继承，问自己两个问题：（1）派生类是它继承的事物的一种特殊类型吗（2）基类是派生类的一部分吗
（57）如果在面向对象的设计中找到多个继承关系，请确保没有基类实际上是另一个基类的派生类。
（58）在面向对象设计中，如果需要在包含关系和关系之间做出选择，请选择包含关系。
（59）不要使用全局数据或全局函数来使用类对象的细化工作，应该使用类变量或类方法。
（60）面向对象的设计人员不应允许物理设计标准破坏其逻辑设计，然而，在逻辑设计决策过程中，我们经常使用物理设计准则。
（61）不要绕过公共接口来修改对象的状态。
