※ 引述《milonga332 ( U U)》之銘言： : 小弟多年前在一家公司上班，負責寫Android App : 公司裡的神級前輩規定，寫Java要避免使用getXXX/setXXX作為method的命名習慣 : 要改用readXXX/writeXXX，或retriveXXX/putXXX...之類的都可以 : 當時試著詢問原因，不過只被冷眼酸了一頓 : 雖然現在已經不在該公司了，不過仍然好奇可能的理由是什麼，不曉得有沒有人知道呢？ 寫 email 問他，為何不能用標準 java bean 的寫法， 他不理就算了，結案啊。 （不然你說一下公司，讓在職的鄉民替你問啊） : p.s. 神級前輩似乎是死硬的微軟派，對於Java十分不屑 : 也許跟C#/.net的命名習慣有關？... 跟討論無關的引戰詞語就免了吧。 真實的工作環境，其實該用什麼時，就會用什麼。 才不管 provider 或 solution 是哪家公司出的， 只有合不合理（時程、預算、後續維護成本）的考量。 推薦閱讀 [1] Getter、Setter的用與不用 https://www.ithome.com.tw/voice/98804 Get rid of getter and setter, toward domain driven design https://ingramchen.io/blog/2009/11/ get-rid-of-getter-and-setter-toward-domain-driven-design.html (短：http://bit.ly/2DaJA3q) 推薦閱讀 [2] Method prefix convention https://ingramchen.io/blog/2011/07/method-prefix-convention.html 在 naming 上不用 getter/setter 後，也得在內部對 prefix 有點共識。 >> : 要改用readXXX/writeXXX，或retriveXXX/putXXX...之類的都可以 read/write 對我來說，會想到 Disk IO retrive 對我來說，會想到要跟 data gateway 或 storage (db, nosql, searchengine) 取資料等 network IO 的東西。 put 直覺像是做 memory data 的覆寫 (如同我們對 Map 做 put 一樣的動作) 我們的「禁止與懲罰」文化另人困惑的地方是，只跟你說不能、不該這麼做。 或沒說明建議的依循準則與背後的原因，於是傳承就這麼中斷了。 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.250.149.207 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/java/M.1515816367.A.F3B.html ※ 編輯: qrtt1 (111.250.149.207), 01/13/2018 13:15:53