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)