※ 引述《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来决定转换的动作了。
以上为小弟个人浅见, 或许举例不好, 但概念上是这样,
若有不适当的设计概念, 还请各位版上大大们指教~~~