Re: [問題] 命名習慣為何完全用readXXX取代getXXX

看板java作者 (接下來如何?)時間6年前 (2018/01/12 00:12), 編輯推噓3(309)
留言12則, 5人參與, 6年前最新討論串2/4 (看更多)
※ 引述《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://www.ptt.cc/bbs/java/M.1515687164.A.127.html

01/12 02:28, 6年前 , 1F
這是method不是純粹的property的情況吧
01/12 02:28, 1F

01/12 02:29, 6年前 , 2F
本來會用get/set的寫法的邏輯就是只有property才用,其他
01/12 02:29, 2F

01/12 02:29, 6年前 , 3F
method避免,但前篇原po沒說他們的規則是這種還是一律避免
01/12 02:29, 3F

01/12 11:03, 6年前 , 4F
get/set我也認為用於property 就好,早期看method也這
01/12 11:03, 4F

01/12 11:03, 6年前 , 5F
樣用,很難判斷用什麼手法去處理
01/12 11:03, 5F

01/13 00:50, 6年前 , 6F
要轉JSON,應該會設計annotation來註解不處理的field
01/13 00:50, 6F

01/13 02:14, 6年前 , 7F
用annotation來免除序列化不是更清楚嗎?
01/13 02:14, 7F

01/13 02:17, 6年前 , 8F
另外要轉json的class最好是純粹的ds 有sum有點雜
01/13 02:17, 8F

01/13 02:18, 6年前 , 9F
(雖然這太過理想化了XD)
01/13 02:18, 9F

01/14 17:48, 6年前 , 10F
瞭解你的意思,至少這是一種可能的方向沒錯
01/14 17:48, 10F

01/14 17:50, 6年前 , 11F
也許在奇怪的環境或限制下會需要這樣的做法
01/14 17:50, 11F

01/14 17:51, 6年前 , 12F
不過當時做的是相當普通的App,總覺得有更好的做法
01/14 17:51, 12F
文章代碼(AID): #1QLupy4d (java)
討論串 (同標題文章)
文章代碼(AID): #1QLupy4d (java)