《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 。