阿里java开发规范学习笔记 (一)命名规范 (二)常量定义

阿里java开发规范:

本规范给出了范例,便于理解

结合自己在项目中的体会,放在【】之中。

编程规约
(一) 命名风格
3. 【强制】类名使用UpperCamelCase风格,必须遵从驼峰形式,但以下情形例外:DO / BO / DTO / VO / AO


【这个是基本都知道的,但是面对一些专有名词,常常不知道应该是大写还是小写,写的时候偶尔XML ,Xml混写,导致最后维护代码最终统一造成麻烦】


例如:TCP or Tcp 
      XML or Xml
      DB  or Db
      WSDL or Wsdl
目前根据阿里指南,之后这种专用名词还是采用驼峰。
正例:MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion
反例:macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion


8. 【强制】POJO类中布尔类型的变量,都不要加is,否则部分框架解析会引起序列化错误。 


【用eclipse生成get set方法的时候,由于返回值为boolean ,自动生成的方法名会再其前面加“is”,跟变量名+is会有冲突】


反例:定义为基本数据类型Boolean isDeleted;的属性,它的方法也是isDeleted(),RPC
框架在反向解析的时候,“以为”对应的属性名称是deleted,导致属性获取不到,进而抛出异常。


12. 【推荐】如果模块、接口、类、方法使用了设计模式,在命名时体现出具体模式。 
刚开始接触java的时候,还不知道设计模式,根据以前写C的方式写,后来才知道是简单工厂模式。设计模式在其他语言经常见,例如单例模式,真的是经验总结出来的。


【将设计模式体现在名字中,有利于阅读者快速理解架构设计理念】
正例:public class OrderFactory; public class LoginProxy; public class ResourceObserver;


13. 【推荐】接口类中的方法和属性不要加任何修饰符号(public 也不要加),保持代码的简洁性,并加上有效的Javadoc注释。
尽量不要在接口里定义变量,如果一定要定义变量,肯定是与接口方法相关,并且是整个应用的基础常量。


【在代码评审中,由于入参出参 命名不准,加上没有javadoc的注释,完全看不懂服务接口的用途】


14. 接口和实现类的命名有两套规则: 
1)【强制】对于Service和DAO类,基于SOA的理念,暴露出来的服务一定是接口,内部的实现类用Impl的后缀与接口区别。 正例:CacheServiceImpl实现CacheService接口。 
【这条项目组也要求强制满足,带来的好处特别明显,接手别人的代码,一来就能找到出入口和具体实现。
不仅这么命名,我们的接口都是xxx.xxxx.xxxx.api 对应的实现都在xxx.xxxx.xxxx.api.impl包下】


2) 【推荐】 如果是形容能力的接口名称,取对应的形容词做接口名(通常是–able的形式)。 正例:AbstractTranslator实现 Translatable。
【这条经常用在定义接口的能力上,用able非常能够体现出使用】


16. 【参考】各层命名规约: 
A) Service/DAO层方法命名规约 
1) 获取单个对象的方法用get做前缀。 
2) 获取多个对象的方法用list做前缀。 
3) 获取统计值的方法用count做前缀。 
4) 插入的方法用save/insert做前缀。 
5) 删除的方法用remove/delete做前缀。 
6) 修改的方法用update做前缀。 
【现在所有的获取都取名为get ,对于多个对象的获取可以更详尽的命名】


B) 领域模型命名规约 
1) 数据对象:xxxDO,xxx即为数据表名。 
2) 数据传输对象:xxxDTO,xxx为业务领域相关的名称。 
3) 展示对象:xxxVO,xxx一般为网页名称。 
4) POJO是DO/DTO/BO/VO的统称,禁止命名成xxxPOJO。
【之前项目组开会讨论,数据可和dubbo调用的类的命名,表示我们命名错了。。DO对应数据库表读取出来的对象,DTO对应dubbo 服务调用对象】


(二) 常量定义


3. 【推荐】不要使用一个常量类维护所有常量,按常量功能进行归类,分开维护。 说明:大而全的常量类,非得使用查找功能才能定位到修改的常量,不利于理解和维护。
正例:缓存相关常量放在类CacheConsts下;系统配置相关常量放在类ConfigConsts下。
【目前工程对这方面不规范,喜欢将所有的常量放在一个路径下,并且将所有的参数注入也放在一个类之中,其实应该根据这些常量所属功能所在类进行划分】


4. 【推荐】常量的复用层次有五层:跨应用共享常量、应用内共享常量、子工程内共享常量、包内共享常量、类内共享常量。 
1) 跨应用共享常量:放置在二方库中,通常是client.jar中的constant目录下。 
2) 应用内共享常量:放置在一方库中,通常是modules中的constant目录下。 反例:易懂变量也要统一定义成应用内共享常量,两位攻城师在两个类中分别定义了表示“是”的变量:
感受:现在工程没有采用两方库的方式,定义的api等函数是由客户端直接粘贴而来,而不是定义了公用接口包。
这样会带来两边的参数完全依赖客户端修改了的同学是否通知了调用端的同学同步他的代码,不同步会出现各类异常:
例如:找不到函数,找不到变量名而无法赋值,序列化的变量不正确。


【此外定义两方包的好处还在于同步两边对于某一String类型 int类型的常量值】
反例:类A中:public static final String YES = "yes"; 
类B中:public static final String YES = "y"; 
A.YES.equals(B.YES),预期是true,但实际返回为false,导致线上问题。


5. 【推荐】如果变量值仅在一个范围内变化,且带有名称之外的延伸属性,定义为枚举类。下面正例中的数字就是延伸信息,表示星期几。 
正例:public Enum { MONDAY(1), TUESDAY(2), WEDNESDAY(3), THURSDAY(4), FRIDAY(5), SATURDAY(6), SUNDAY(7);}


【现有工程采用的比例子更好一点的定义,将1,2,3,4这种常量的含义定义在一个常量池,毕竟工程中3,4,5,6,7这种都会被检测为魔法值。
例子:
错误码按照系统分前缀
public enum ErrorCodePrefix {
    REGISTER(Constants.REGISTER_SERVICE_NO),//Constants.REGISTER_SERVICE_NO=01
    DBOPERATION(Constants.DB_SERVICE_NO);//Constants.DB_SERVICE_NO=02
}


枚举可以定义的更全面。现有工程使用的复杂枚举。
public enum ResponseEnum {
    SUCCESS(TransErrType.SUCCESS, "0000", "处理成功"),
    NOT_FOUND(TransErrType.FAILED, "0001", "没有找到对应信息"),
    NODE_NOT_EXIST(TransErrType.FAILED, "0001", "不存在");
    
    ResponseEnum(short errType, String errCode, String errDesc) {
        this.errType = errType;
        this.errCode = errCode;
        this.errDesc = errDesc;
    }
}】



  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值