《Java开发手册》始于阿里内部规约,在全球Java开发者共同努力下,已成为业界普遍遵循的开发规范,手册涵盖编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程规约、设计规约七大维度。
手册自发布以来,有超260万开发者下载,相关的规约插件在GitHub上获得了20000+星的支持,4月22日8点泰山版《Java开发手册》正式发布,你有什么想对作者提问的,想和其他Java开发者交流的?可以把你想交流的问题发在评论区。请注意:你的评论将有机会收到手册作者孤尽的直接回复哦!
我们将在评论区挑选5位提出优质问题/建议的同学,送出社区周边纪念品。
提问:《泰山版》【P43页:工程结构-应用分层-分层领域模型规范】
Q1:对于BO的理解不知道是否准确,BO是同业务的一个封装对象,内部可能调用了多个该业务相关的Service层方法是吗?
Q2:对于Query、VO的理解,Query是Controller层的接收查询请求对象,VO是Controller层返回的响应对象呢?但是Controller层接收Update/Add等操作时,该用什么模型去定义呢?以及模型定义规范推荐如何呢?
Q3:对于DTO的理解,DTO是Service层向外输出的传输对象,那Service层接收的请求对象建议是用什么模型定义呢?如果Service层查询请求模型也用Query,与Controller一致,是否会影响复用性呢?
建议:对于分层模型的定义和使用,网上确实还是蛮多不一样的见解的,建议可以推出分层模型在各层出入参使用的示意图,便于读者理解。
泰山版《Java开发手册》—第8页—第四章节OOP规约—第9点:关于浮点数之间等值判断的强制规约,我个人觉着不合理,或者是描述不够准确。以下为个人理解,如有错误,敬请指出,感谢!
基本类型不能用==,包装类型不能用equals,这应该限于特定场景,即做等值判断的两个对象是经过计算得来的,该场景下的等值判断会由于浮点数计算不精确,而导致判断结果与预期不符,其背后原因是计算机的二进制无法精确表示浮点数。
如果做等值判断的两个对象不是经过计算得来,那么并不会因为计算损失精度而导致判断失败,这种情况下用==和equals判断未尝不行,毕竟包装类还重写了equals方法,floatToIntBits和doubleToLongBits分别将Float和Double转成int和long,然后用==来判断。
泰山版P8,(三)代码格式,第5条,正例中描述错误: ** “// 关键词if与括号之间必须有一个空格,括号内的f与左括号,0与右括号不需要空格”**, 但示例代码中并没有空格。
建议1:if与左括号之间没有空格; 建议2:右括号与左大括号中间有一个空格
不知道是不是问题。 手册中(四)OOP规约 第9条 提到可以用BigDecimal的equals方法比较浮点数等值,这个有问题的。
BigDecimal a = new BigDecimal("0.1");
BigDecimal b = new BigDecimal("0.10");
// 这个是false
System.out.println(a.equals(b));
// 这个才是0
System.out.println(a.compareTo(b));
踩过这个坑,equals根本不适用于判断等值,还是得用compareTo()方法
错别字? P28: 说明:对大段代码进行 try-catch,使程序无法根据不同的异常做出正确的应激反应,也不利于定位问题,这是一种不负责任的表现。
建议手册把相较于上个版本的手册 新增或者修改的规约都加上特定的标识符。以使得持续学习者可以重点关注这些新增和修改。
附 2:专有名词解释 1. CAS(Compare And Swap):~~ 阿里巴巴专指数据库表一一对应的 POJO 类。~~解决多线程并行 情况下使用锁造成性能损耗的一种机制,这是硬件实现的原子操作。CAS 操作包含三个操作 数:内存位置、预期原值和新值。如果内存位置的值与预期原值相匹配,那么处理器会自动将 该位置值更新为新值。否则,处理器不做任何操作。 2. DO(Data Object): 阿里巴巴专指数据库表一一对应的 POJO 类。
重复了。
终极版:9. 【强制】表必备三字段:id, gmt_create, gmt_modified。 华山版:9. 【强制】表必备三字段:id,create_time,update_time。 泰山版:9. 【强制】表必备三字段:id, gmt_create, gmt_modified。
怎么又变回去了?
正例:用户注册的场景中,如果用户输入非法字符,或用户名称已存在,或用户输入密码过于简单,在程序上作出分门别类的判断,并提示给用户。
第3条正例中的注册案例,根据不同的注册异常给出不同的响应。 是否与第2条不要用异常做流程控制和条件控制
和我理解的第1条可以通过预检查方式规避的异常不应该通过catch的方式来处理
的思路冲突呢?不管是非法字符或用户名称已存在或输入密码过于简单都是可以通过预检查方式规避的异常。
以前没太仔细考虑异常处理的问题,都是自定义异常直接抛。前段时间修改以前的demo,原本是像示例这样把校验失败都算作异常,但在一些论坛中的讨论贴看到说这样是滥用异常,于是就修改成做预检查用返回值来控制参数和权限校验这部分,但改完还是说不出来这两种处理方式的好坏。
手册里所说的这两条内容,没理解到位,关于用异常还是用预检查返回值控制流程的问题比较纠结。希望各位老师能帮我解惑,谢谢
泰山版JAVA开发手册中有关于jni的部分吗?如果没有的话,后续可以加上去哦,把c和c++规范一下,手册的名字我都想好了,叫珠穆朗玛峰版JAVA开发手册,\手动滑稽
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。