作者NullLife (接下来如何?)
看板java
标题Re: [问题] 命名习惯为何完全用readXXX取代getXXX
时间Fri Jan 12 00:12:40 2018
※ 引述《milonga332 ( U U)》之铭言：
: 小弟多年前在一家公司上班，负责写Android App
: 公司里的神级前辈规定，写Java要避免使用getXXX/setXXX作为method的命名习惯
: 要改用readXXX/writeXXX，或retriveXXX/putXXX...之类的都可以
: 当时试着询问原因，不过只被冷眼酸了一顿
: 虽然现在已经不在该公司了，不过仍然好奇可能的理由是什麽，不晓得有没有人知道呢？
: p.s. 神级前辈似乎是死硬的微软派，对於Java十分不屑
: 也许跟C#/.net的命名习惯有关？...
我不确定你前辈的考量, 但说说我个人经验。
现在很流行将物件序列化为json丢来丢去
而最常使用的转换工具就是就是jackson
然後它预设看到field就会去找get/set来调用
也就是要将物件转成json时,
jackson会去扫所有field然後找到有get的field全都转出来
当今天物件是一个pojo, 里面会许有A, B, C三个field(int)
然後这个pojo有个特别的逻辑是, set A时就把值加到另一个field sum里,
set B时一样加到sum里, set C时一样, 当重新set A时会将sum扣掉旧A然後加上新A,
依此类推。
因为因为业务逻辑关系, A B C三个值与其sum会时常被取出使用或者调整,
所以这样设计该pojo, 所以sum有点像是cache的概念,
但今天如果想要将这个物件转成json传递时，sum就会是一个杂讯(像是RDB的第三正规化)
因此如果大家都写了get/set, sum也会被jackson转出
所以这时候我就会将sum的get/set采用take/put来取代
(以此例来说的话, sum其实我就不会写put了)
这或许有点挑战大家不成文的规定
(就像我觉得在有IDE的时代，
还将泛型写成T、K等完全不能表达含意字母是很不洽当的写法一样)
但我觉得同个专案内定义清楚即可, 专案参与者跟着走就好
而且这样还有个好处, 一眼就知道该值是相依於其他field的值
而这样改写的好处就是
1.被转换的物件不需要特别注明序列化的特例
2.序列化工具也不需要针对该类有特别的处理, 继续保有default的序列化逻辑
PS:
我个人认为pojo是不继承也不实作任何类, 及"只"相依於java原生class
不相依任何自定义、第三方class的类就视为pojo。
因此这情况下就不考虑使用jackson的annotation来决定转换的动作了。
以上为小弟个人浅见, 或许举例不好, 但概念上是这样,
若有不适当的设计概念, 还请各位版上大大们指教~~~
--
为什麽不说话 为什麽打哈欠
今天的天气这麽好 怎麽还愁眉苦着脸
让我们喝咖啡 让我们听音乐
让我们跨越了界线 让我们自在的聊天
黄玠
让我们每天心情都是星期天
生活一堆毛
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 123.193.209.100
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/java/M.1515687164.A.127.html
1F：→ ssccg: 这是method不是纯粹的property的情况吧 01/12 02:28
2F：→ ssccg: 本来会用get/set的写法的逻辑就是只有property才用，其他 01/12 02:29
3F：→ ssccg: method避免，但前篇原po没说他们的规则是这种还是一律避免 01/12 02:29
4F：推 zephyrhymn: get/set我也认为用於property 就好，早期看method也这 01/12 11:03
5F：→ zephyrhymn: 样用，很难判断用什麽手法去处理 01/12 11:03
6F：推 jtorngl: 要转JSON，应该会设计annotation来注解不处理的field 01/13 00:50
7F：→ cha122977: 用annotation来免除序列化不是更清楚吗？ 01/13 02:14
8F：→ cha122977: 另外要转json的class最好是纯粹的ds 有sum有点杂 01/13 02:17
9F：→ cha122977: (虽然这太过理想化了XD) 01/13 02:18
10F：推 milonga332: 了解你的意思，至少这是一种可能的方向没错 01/14 17:48
11F：→ milonga332: 也许在奇怪的环境或限制下会需要这样的做法 01/14 17:50
12F：→ milonga332: 不过当时做的是相当普通的App，总觉得有更好的做法 01/14 17:51