※ 引述《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來決定轉換的動作了。
以上為小弟個人淺見, 或許舉例不好, 但概念上是這樣,
若有不適當的設計概念, 還請各位版上大大們指教~~~