Java面向对象设计的61条原则

（1）所有数据都应隐藏在其所在的类内.

（2）类的用户必须依赖于类的公共接口，但是类不能依赖于其用户.

（3）最小化类协议中的消息.

（4）实现所有类都理解的最基本的公共接口（例如，复制操作（深层复制和浅层复制），相等性判断，正确的输出，从ASCII描述进行解析等）.

（5）不要在类的公共接口中放置实现细节（例如放置通用代码的私有函数）.

如果该类的两个方法都有一段公共代码，则可以创建一个防止这些公共代码的私有函数.

（6）不要以用户无法使用或不感兴趣的方式干扰类的公共界面.

（7）类之间的耦合应该为零，或者只能是派生的耦合关系. 也就是说，一个类与另一个类无关，或者仅在另一个类的公共接口中使用操作.

（8）类只能表示一个键抽象.

包中的所有类都应一起关闭，以改变同一类的性质. 如果更改影响软件包，它将影响软件包中的所有类，但对其他软件包没有任何影响. （9）集中相关数据和行为.

设计人员应注意那些通过诸如get之类的操作从其他对象获取数据的对象. 这种行为意味着违反了这种经验原则.

（10）将不相关的信息放在另一个类别中（即，彼此不交流的行为）.

依靠稳定性.

（11）确保您建模的抽象概念是一个类，而不仅仅是对象扮演的角色. 班级应统一分享作业.

（13）请勿在系统中创建全面的类/对象. 对于名称包括Driver，Manager，System和Susystem的类要特别小心.

计划一个接口而不是实现一个接口.

（14）在公共接口中定义大量访问方法的类要格外小心. 大量的访问方法意味着相关数据和行为不会集中存储.

（15）对于包含过多非交流行为的类要更加小心.

此问题的另一个体现是，在应用程序类的公共接口中创建了许多get和set函数.

（16）在由与用户界面交互的java面向对象模型组成的应用程序中，该模型不应依赖于该接口，并且该界面应依赖于该模型.

（17）在现实世界中尽可能多地建模（为了遵守系统功能分配的原则，避免万能的原则并集中相关数据和行为的放置，我们经常违反该原则. ） （18）从您的设计中删除不必要的类.

通常，我们会将此类降级为属性.

（19）删除系统外部的类.

系统外部类的特征是抽象地java面向对象设计原则，它们仅向系统域发送消息，而不接受系统域中其他类的消息.

（20）不要将操作变成类. 质疑任何名称是动词或派生动词的类，尤其是仅具有一种有意义行为的类. 考虑是否应该将有意义的行为迁移到已经存在或尚未发现的类.

（21）在为应用程序创建分析模型时，我们经常引入代理类. 在设计阶段，我们经常发现许多代理是无用的，应该删除.

（22）尝试减少班级协作者的数量.

一个类使用的其他类的数量应尽可能少.

（23）尝试减少在类和协作者之间传递的消息数.

（24）尝试减少类与协作者之间的协作量，即减少在类与协作者之间传递的不同消息的数量.

（25）最小化类的散布，即减少类定义的消息数与发送的消息数的乘积.

（26）如果该类包含另一个类的对象，则包含类应将消息发送到所包含的对象. 即: 包含关系始终意味着使用该关系.

在类（27）中定义的大多数方法应该在大多数时间使用大多数数据成员.

（28）中包含的对象数量不应超过开发人员的短期存储容量. 该数字通常为6. 当类包含6个以上的数据成员时，可以将逻辑上相关的数据成员划分为一组，然后使用新的包含类来包括该组成员.

（29）让系统功能垂直分布在狭窄而深厚的继承系统中.

（30）在实现语义约束时，最好根据类定义来实现它们. 这通常导致班级泛滥. 在这种情况下，约束应该在类的行为中实现，通常是在构造函数中实现，但这不是必需的.

（31）在类的构造函数中实现语义约束时，请将约束测试置于构造函数字段允许的最深层包含中.

（32）在面向对象的Java中，如果约束所依赖的语义信息经常发生变化，则最好将它们放在一个集中的第三方对象中.

（33）如果约束所依赖的语义信息很少变化，那么最好将其分布在约束所涉及的各个类中.

The

（34）类必须知道它包含的内容，但不能知道是谁包含的.

（35）共享文字范围（即，包含在同一类中）的对象之间不应存在关系.

（36）继承仅应用于对专用层次结构进行建模.

（37）派生类必须知道基类，而基类不应该知道有关其派生类的任何信息.

（38）基类中的所有数据都应为私有数据，并且不要使用受保护的数据.

类设计者绝不应将类用户不需要的东西放在公共接口中.

（39）从理论上讲，继承层次应该更深，越深越好.

（40）在实践中，继承层次的深度不应超过普通人的短期记忆能力. 广泛接受的深度值为6. （41）所有抽象类都应为基类.

（42）所有基类都应该是抽象的.

（43）将数据，行为和/或接口的通用性放在继承层次结构中.

（44）如果两个或多个类共享公共数据（但是没有公共行为），则应将公共数据放在一个类中，并且每个共享此数据的类都包含该类.

（45）如果两个或多个类具有相同的数据和行为（即方法），则这些类中的每一个都应从表示这些数据和方法的公共基类继承.

（46）如果两个或多个类共享一个公共接口（引用消息，而不是方法），则只有在需要多态使用它们时，它们才应从一个公共基类继承.

（47）分析对象类型的显示通常是错误的. 在大多数情况下，设计人员应使用多态性.

（48）分析属性值的显示通常是错误的. 应该将类分离为继承层次结构java面向对象设计原则，并将每个属性值转换为派生类.

（49）不要通过继承对类的动态语义建模. 尝试使用静态语义关系为动态语义建模会导致在运行时切换类型.

（50）请勿将类的对象转换为派生类. 小心任何只有一个实例的派生类.

（51）如果您认为需要在运行时创建一个新类，请退后一步以确认您正在创建对象. 现在，将这些对象归纳为一个类.

（52）用派生类中的空方法（即不执行任何操作的方法）覆盖基类中的方法应该是非法的.

（53）请勿将可选包含与继承需求混为一谈. 将可选包含物建模为继承会导致泛滥.

（54）创建继承层次结构时，请尝试创建可重用框架而不是可重用组件.

（55）如果在设计中使用多重继承，请首先假设您犯了一个错误. 如果您没有记错，则需要尝试证明这一点.

（56）只要在Java面向对象设计中使用继承，就问自己两个问题: （1）派生类是否是继承对象的一种特殊类型？ （2）基类是派生的吗？部分？

（57）如果在面向对象的设计中找到多个继承关系，请确保没有基类实际上不是另一个基类的派生类.

（58）在面向对象设计中，如果需要在包含和关联之间进行选择，请选择包含.

（59）请勿将全局数据或全局函数用于类对象的簿记. 应该使用类变量或类方法.

（60）面向Java的设计人员不应让物理设计准则破坏其逻辑设计. 但是，在逻辑设计决策过程中，我们经常使用物理设计标准.

（61）不要绕过公共接口来修改对象的状态.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-281872-1.html