设计规范-java.doc

设计规范目录1前言32基本规范33面向对象设计基本原则44包的设计原则45面向服务的接口设计规范56待完善61 前言为了更好地指导我们的设计工作，提高设计的质量，我们特制定本规范。规范中的条目分为3类，含义分别如下： Policy：必须遵循的策略，实现方法可以自己考虑，但不能违反策略的规定 Discipline：必须遵守的纪律，必须按照规定中的描述实施，绝对不能违反 Guideline：建议性的指南和规范，将逐步要求大家遵循实施2 基本规范Policy 1-1: 按照公司目前的分层框架，表示层逻辑由Controller完成，业务处理逻辑由Service层完成，数据访问逻辑由DAO层完成，不得简化或混淆。Policy 1-2: DAO层不调用Service，Service层不能调用Controller，Controlle不能直接调用DAO等。Discipline 1-1: 在我们的业务方法中，尽量不要出现和环境紧密的参数，比如ServletContext等, 尽量封装以后再使用。Discipline 1-2: 每个Service有自己的责任，非职责内的功能不应该放在Service代码中，应该由其它类来完成。Guideline 1-1: 接口技术选用的原则，系统之间允许异步处理，并且消息不允许丢失，一般推荐采用MQ传递消息；如果是异构系统，并且必须同步返回处理结果，推荐采用WebService；如果采用同一个DataSource，并且后需操作必须依赖前面操作的持久化数据，推荐采用数据库传递数据。Guideline 1-2: 悲观锁和乐观锁的使用原则，通常并发数量不大，对系统性能要求不是很苛刻，推荐采用悲观锁；而对大并发量的数据操作，系统性能要求很高的，推荐采用乐观锁。3 面向对象设计基本原则Policy 2-1: 单一职责原则（SRP），就一个类而言，应该仅有一个引起它变化的原因，该原则可以有效降低耦合，减少对不必要资源的引用。在实际应用中，可以对经常使用或经常需要改动的模块应用该原则。Policy 2-2: 开放-封闭原则（OCP），对于扩展是开放的（Open for extension），对于更改是封闭的（Close for modification）。提高灵活性、可重用性、可维护性。Policy 2-3: Liskov替换原则（LSP），对每个类型S的对象O1，都存在一个类型T的对象O2，使得在所有针对T编写的程序P中，用O1替换O2后，程序P行为功能不变，则S是T的子类型。也就是说，子类型（subtype）必须能替换掉它们的基类型（base type）。如果一个软件实体使用的是基类的话，那么也一定适用于子类。但反过来的代换不成立。Policy 2-4: 依赖倒置原则（DIP），高层模块不应该依赖于低层模块，二者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。Policy 2-5: 接口隔离原则（ISP），一个类对另外一个类的依赖性应当是建立在最小的接口上的。如果客户端只需要某一些方法的话，那么就应当向客户端提供这些需要的方法，而不要提供不需要的方法。提供接口意味着向客户端做出承诺，过多的承诺会给系统的维护造成不必要的负担。4 包的设计原则Policy 3-1: 重用发布等价原则（REP），重用的粒度就是发布的粒度。Policy 3-2: 共同封闭原则（CCP），包中的所有类, 对于同一类性质的变化应该是共同封闭的。Policy 3-3: 重用发布等价原则（CRP），一个包中的所有类, 应该是共同重用的。Policy 3-4: 无循环依赖原则（ADP），在包的依赖关系图中不允许存在环状。Policy 3-5: 稳定依赖原则（SDP），朝着稳定的方向进行依赖。Policy 3-6: 稳定抽象原则（SAP）, 包的抽象程度应该和其稳定程度一致。5 面向服务的接口设计规范Policy 4-1: 服务接口的方法，避免抛出和返回异常。因为，异常会使外部使用者产生异常依赖；并对异常进行处理。Policy 4-2: 服务接口必须有清晰的文档说明，对于常量定义的参数，要枚举出支持的常量值和说明。Policy 4-3: 服务接口的参数避免使用Object类型，集合类型要指定具体对象类型。因为，当使用Object时，使用者获取到WSDL文件时，不知道该传递什么业务数据，如果是异构系统，比如，其它语言的调用者，更无法理解了；这类接口设计违反了业务SOA的原则，暗含着如下潜台词：业务上不明确的，不清晰的。 Policy 4-4: 服务接口避免使用集合类型，尽可能使用数组类型。 因为，集合类型在序列化的时候也可能出现问题。而且使用数组类型，具体的业务对象很明显直接。Policy 4-5: 服务接口中尽量避免使用枚举对象，因为枚举造成了外部调用者的依赖，实在无法避免，要有清晰化的文档说明。Discipline 4-1: 服务接口的方法，建议放弃OO的overload特性。因为服务接口在序列化时，overload可能产生问题。另外，在面向服务领域，overload本身就不是一个特性。 Discipline 4-2: 服务接口尽可能把查询和业务方法分离。因为在使用AOP事务时简单方便，另外，对于查询方法进行特殊处理时也比较方便，例如：与cache整合、与特殊权限要求进行整合、对返回信息按照权限进行过滤等。Discipline 4-3: 在服务接口传递的参数数量较多，通常是3个，建议将参数封装成可序列化的对象进行传递。Discipline 4-4: 服务接口避免设计成面向数据的操作，例如：updateStatus。这类接口，通常包含太多的业务含义，需要外部使用者去理解或猜测业务内部的细节。服务接口就是要对外部屏蔽业务内部是如何存储的，结构是什么样的，避免服务内部发生重构、变化时，外部使用也需要进行关联变化。 Discipline 4-5: 服务接口的方法名尽量避免以：is，get开头，用find，check等来代替之，感觉更加面向服务。Guideline 4-1: 服务接口层内部建议设计一个统一的模板框架，来处理服务上下文（例如：ServiceContext）、事务、异常处理、日志、事件、审计等具有共性的行为。Guideline 4-2: 服务接口参数排列按照如下原则：操作主体对象或ID，业务参数，环境参数。例如：verifyPassword(String operatorId, String password, ServiceContext serviceContext) ， operatorId是操作主体的ID，Password是密码，serviceContext是环境参数。 Guideline 4-3: 业务处理类接口，返回值可以采用统一对象模式。例如：ServiceResult： public class ServiceResult implements Serializable private boolean isSuccess;private String resultCode; 采用这种模式，实际是按照协议的角度进行设计，所有服务按照统一的包装模式返回。 6 待完善Policy 5-1：统一的常量定义设计规范，对一些枚举对象、不同的模块/层级的常量定义，需遵循统一的设计规范。Policy 5-2：统一的前端架构设计，对前端的js、css、ja