This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: getters/setters
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
Blaine comes down as a pragmatist, stating that the most important thing is consistency - either use them or don't, but don't mix and match styles. I have a slightly different perspective, but it's colored by my experience developing BottomFeeder. One of the things I added early was the ability to have the app update itself on the fly. Smalltalk has always been capable of this, so I thought it would be a nice way of tooting that horn. Using direct variable access is problematic if you are going to update an app on the fly. Why?
Well, posit a method foo that directly accesses a variable bar - the older version (i.e, the one being replaced) was written before that variable had been added to the class in question. So I access the variable... and as soon as I try to send a message to it I'm likely to get an exception. When I add a new variable to a class, it gets initialized to nil, so I have one of two choices:
I can wrap all direct accesses with a nil check
I can simply add a getter method that does lazy initialization
The former is a more annoying version of the latter, and scatters the same initialization logic all over the class - which violates the once and only once principle. Now, this kind of thing never comes up in Java, because you can't add attributes to a class at runtime there - you would need to restart. For that reason, Java developers simply aren't going to come across this messy little use case for getters. That's why I tend to use getter methods - it makes runtime updating of code far, far simpler.
Previous Topic
