Dave Buck and Blaine have a couple of good posts up on the whole getter/setter issue (are they good/bad/indifferent). In the two projects I run - BottomFeeder and Silt - I tend to always have getters for instance variables. The rationale for that is pretty simple - I update both applications on the fly.

Silt is the server that runs this blog, and I patch it with bug fixes and new capabilities on the fly. Just recently, I added some information for the writers - the current number of pageviews that have been requested. I have the basic log scraping done by a cron job, and the specific count parsing done when it's requested. That's a somewhat expensive operation, as it involves dealing with large external files. So, I have the results cached, and the cache tossed whenever the file is updated.

I added the cache as an update - which means that direct variable access would be problematic. When you add a new instance variable to a class in Smalltalk, it gets added to all the extant instances as well - with a value of nil. Sure, I could write a script that makes sure they all get the right values. Or, I could do what I've been doing - make the getter a lazy initializer, and just have all accesses go through the getter.

I have similar reasons for doing this in BottomFeeder. I allow updates on the fly when new components are available on the download site. That means the dynamic reloading of a parcel, which gets into all the same issues I just went into above. So - lazy getters.

Which is why I said that I have getters for all new variables for pragmatic reasons. It just makes my ongoing maintenance job a whole lot simpler. Depending on how your application works, and whether it can get updated on the fly, your needs - and your code - may well vary.