Write code with no getters???
Learning notes June 17th, 2008
One of my friends shared a blog post to me, at first it looks like quite a good practice, however after I read and think over I feel I am quite disagree with this guy. It’s a quite interesting debate, I am wondering if you guys like it or have your opinions.
In this blog (http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html ), someone tell a story that write code without setter will have great benefit for TDD:
“John Nolan, gave his developers a challenge: write OO code with no getters. Whenever possible, tell another object to do something rather than ask. In the process of doing this, they noticed that their code became supple and easy to change. They also noticed that the fake objects that they were writing were highly repetitive, so they came up with the idea of a mocking framework that would allow them to set expectations on objects - mock objects.”
Someone(http://peripateticaxiom.blogspot.com/2008/06/tdd-mocks-and-design.html ) extended his idea and provided a code sample:
“Suppose that we want to print a value that some object can provide. Rather than writing something like
statement.append(account.getTransactions())instead we would write something more likeaccount.appendTransactionTo(statement)We can test this easily by passing in a mocked statement that expects to have a call likeappend(transaction)made. Code written this way does turn out to be more flexible, easier to maintain and also, I submit, easier to read and understand. (Partly because) This style lends itself well to the use of Intention Revealing Names.”
Those idea looks great at the first sight, but at least for me I complete can’t agree with the second guy, I feel what he *suggested* is what I will *avoid*. Maybe he just gave a bad sample, however from his blog’s long debate it looks like he is quite confident with his idea.
Reference reading:
Getter/Setter debate: http://moffdub.wordpress.com/2008/06/16/the-getter-setter-debate/
Getter Eradicator: http://martinfowler.com/bliki/GetterEradicator.html
Why getter/setter are evil: http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
Doing it wrong: getters & setters: http://typicalprogrammer.com/?p=23
–
I would like to hear your opinions….
About
Hey, thanks for the link.
The comment I left on the Typical Programmer blog has calmed me down on this issue — yeah, Eric Evans has that sort of influence over me — that you avoid them as much as possible, but for the sake of UI mapping, O/R mapping, proxies/lazy loading, and possibly other patterns, you need the pesky getters.
I imagine that it can help out a lot if you give the getters some descriptive and discouraging names, and during code reviews, you can keep careful track of who uses them and why.
Another more sophisticated and automated approach could be to develop a pattern of sorts in which an external “watcher” object regulates which classes use the getters.
Hey, thanks for the link. I think the overall point that you shouldn’t overuse getters is correct. If you’ve ever read or seen Smalltalk code (so-called “true” OO), it is all messages between objects, asking them to get stuff done.
The comment I left on the Typical Programmer blog has calmed me down on this issue — yeah, Eric Evans has that sort of influence over me — that you avoid them as much as possible, but for the sake of UI mapping, O/R mapping, proxies/lazy loading, and possibly other patterns, you need the pesky getters.
I imagine that it can help out a lot if you give the getters some descriptive and discouraging names, and during code reviews, you can keep careful track of who uses them and why.
Another more sophisticated and automated approach could be to develop a pattern of sorts in which an external “watcher” object regulates which classes use the getters.
Hi, I am the “someone”. I am very confident about this technique because I have successfully written code this way for years, and I know a number of other people who have too.
I invite you to try this way of writing code, you might be pleasantly surprised.
I have written a post on my blog detailing a pattern-based solution to this problem:
http://moffdub.wordpress.com/2008/07/01/method-regulator-pattern/