《Java开发手册》v1.5.0 华山版编码规约解读之命名风格
1.1 POJO 命名规约
最近在看《Java开发手册》v1.5.0 华山版，看到编码规约中有这么一条：
感觉这些名词如果用的不多，会容易混淆,因此相关解释汇总如下：
| 专业术语 | 解释 |
|---|---|
| DO | DO（Domain Object）,与数据库表结构一一对应，通过DAO层向上传输数据源对象。xxxDO，xxx即为数据表名 |
| BO | BO（ Business Object）：业务对象。 由Service层输出的封装业务逻辑的对象. |
| DTO | DTO（ Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。xxxDTO，xxx为业务领域相关的名称 |
| VO | VO（ View Object）：显示层对象，通常是Controller Web层向模板渲染引擎层传输的对象。xxxVO，xxx一般为网页名称 |
| POJO | POJO（ Plain Ordinary Java Object）,POJO是DO/BO/DTO/VO的统称，禁止命名成xxxPOJO.在本手册中， POJO专指只有setter/getter/toString的简单类，包括DO/DTO/BO/VO等。 |
| AO | AO（ Application Object）：应用对象。 在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。 |
| PO | PO（Persistent Object）持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性 |
| UID | UID 用户身份证明(User Identification)的缩写 |
1.2 Service/DAO层方法命名规约
- 获取单个对象的方法用get作前缀。
- 获取多个对象的方法用list作前缀。
- 获取统计值的方法用count作前缀。
- 插入的方法用save/insert作前缀。
- 删除的方法用remove/delete作前缀。
- 修改的方法用update作前缀。
1.3 抽象类命名规约
抽象类命名使用 Abstract 或 Base 开头 ；
1.4 异常类命名规约
异常类命名使用 Exception 结尾 ；
1.5 布尔类型变量命名规约
【强制】 POJO 类中布尔类型的变量，都不要加 is 前缀 ，否则部分框架解析会引起序列化错误。
反例：定义为基本数据类型 Boolean isDeleted 的属性，它的方法也是 isDeleted() ， RPC 框架在反向解析的时候，“误以为”对应的属性名称是 deleted ，导致属性获取不到，进而抛
出异常。
1.6 接口和接口实现类命名规约
接口和实现类的命名有两套规则：
- 【强制】对于 Service 和 DAO 类，基于 SOA 的理念，暴露出来的服务一定是接口，内部的实现类用 Impl 的后缀与接口区别。 正例： CacheServiceImpl 实现 CacheService 接口。
- 【推荐】 如果是形容能力的接口名称，取对应的形容词为接口名 （ 通常是– able 的形式 ） 。 正例： AbstractTranslator 实现 Translatable 接口 。
1.7 枚举类型命名规约
【参考】枚举类名建议带上 Enum 后缀，枚举成员名称需要全大写，单词间用下划线隔开。
- 说明：枚举其实就是特殊的类，域成员均为常量，且构造方法被默认强制是私有。
- 正例：枚举名字为 ProcessStatusEnum 的 成员名称： SUCCESS / UNKNOWN _ REASON 。
参考资料
