getter/setter 的問題不在於是否 "getter/setter 9 成 以上都只有簡單的取值" (外國十年前就在戰的根本不是 這東西), 或是 "getter/setter 算不算 encapsulation" (我明顯是來亂的, L 君和 P 版大的論點我都在反對 :P ) 首先要解釋的是所謂外國十年前就在戰的是什麼. 其實 根本就沒有什麼在戰的. 事緣是有一個滿熱絡的討論, 在 談 "getters/setters are evil". 然後就有人沒有看清楚 因由, 就把這題目想成: 「因為絕大部份 setter/getter 都只是單純設值取值所以多餘,所以倒不如直接 access attribute」 然後就丟出一堆理由說setter/getter 比直 接取值好(大部份像 L 君那篇文說那堆) 可是那篇文的論點根本就不是這方面的東西. 所謂 setters/getters are evil 並不是說你不該用 setter getter 而轉用直接存取 attribute. 這可是比 setter/getter 更差. 所謂 evil 在談的是, 現今大部份人的所謂 OOP 設計, 裡面 大部份的 class 都旨在提供 getters/setters, 然後把 logic 寫在某些特定的地方 (XXX Service, XXX Manager etc), 而所謂 的 logic 則是不斷經 getter/setter 存取一堆不同的 class. 但這並不是好的 OOP 設計, 這也不是包裝. OOP 說的是 讓你的 class 提供各種有意思的行為, 而不必讓你的 class 洩露 它的內部結構. 這才是所謂包裝, 才是 getter/setter are evil 的意思. 要是理解後, 就會明白這和 所謂 interface-driven 關係密切. 然後下一個問題是, 是不是 getter/setter 就有問題? 不是 有很多情況下我們的確要讓人存取資料, 最常見的就是有些 class 的確就是設計來放數值給人家看的, 這類 data object 最常 見用於 marshall/demarshall 為 serialized form. 另外一種常見的用途就是 component 用來建立關係用的, 比如 OrderService 會用 AccountService, 我要怎麼令我的 OrderServiceImpl instance 指向某一 AccountService 的 instance, Dependency Injection 的場合, setter 甚為重要. (當然還有其他情況) 所以一看到 getter/setter 就說白痴的, 只是知其然而不知其 所以然. 問題不是在於 "你 90% 的 bean 的 getter/setter 都只是單純存取", 而在於 "你的設計裡 90% 都只是單純提供 getter/setter 存取的 bean". L 君說的一句: "只要OBJECT 都要 GET/SET 一下" 比較貼近問題所在, 唯這種作風並不是在 java 才發揚光大. 一堆寫 C++ 的人早就這樣做了. 只是 Java (其實是 Java Bean) 對 getter setter 有比較正式的規範而已. 同樣, 在爭論 getter/setter 在做封裝的, 也是方向錯誤. 99% 的 getter/setter 就不是作封裝的. 而這種 getter/setter 的確在洩露 implementation detail. 當然和直接存取 field 相比, 經 getter/setter 還是 有好處. 但 OOP 的目的是讓你 的 domain model 提供有意思的行為, 而不是搞 Anemic model + service 這種 名 OOP 實 procedural 的設計. --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 91.240.192.5 ※ 編輯: adrianshum 來自: 91.240.192.5 (03/13 16:36)