Why Your Code Sucks
Intersting debate came from reading Why Your Code Sucks. One useful quote was "Code should be easy to read. Steve McConnell made the statement at his SD West '04 keynote that code should be convienent to read, not convienent to write." Even Joel Spolsky wrote in his rant on refactoring that the hardest thing for software developers to do is read and grok other developers code...they often find it easier to just throw away and re-write. Optimizing for reading makes sense when you start thinking about it.
Great comments on frameworks, again re-inforcing concepts about why our approach to BSF may have been fatally flawed in some cases, and good in others.
----
A few great criticisms from Steve Yegge:
But I'm not inclined to agree with him about removing getters and setters and opening up field access for "transparently readable and writeable" variables.
Doing this is playing with fire, and suggesting it reflects poorly on the author of the article.
If you simply create a publicly writeable field, you have no way of knowing when the field changes, and who's changing it. Just *think* how awful your debugging would be. With an explicit setter, you know exactly when the field changes, and using (e.g.) Thread.getStackTrace(), or Thread.dumpStack() pre-1.5, you can figure out exactly who's changing it.
You can use this info for debugging, or for profiling (e.g. put in a counter that increments every time you call the setter), or for logging, or even as a way to provide hooks -- e.g. you could add a Listener mixin interface that's called back every time the setter is called.
With getters and setters, you can change the behavior in a subclass. Rather than accessing a private data field, for instance, a subclass could call out to some other data store to get the value. And then it could keep the value cached.
Java doesn't provide a way to make a public field directly readable but only writeable through a method. So if you want to force write-access through a setter, you need to make the variable non-public and add a getter as well. Jython and presumably Groovy actually do the "right thing" (at least the article guy would think so), since this:
x = foo.a
actually invokes a getA() method via beany reflection, if there are appropriate getA and setA methods. So it has the advantage of being clearer and more readable, and is also trackable.