More on getters and setters

Giving up procedural idioms is neither easy nor comfortable. Too many things that are "right" in a procedural context are "wrong" in an OO context. I've heard many lame excuses for staying in the procedural comfort zone. One of the contributors to the previous article's discussion, for example, claimed that hard-core data abstraction such as I've described was worthless in situations where maintenance was not important, which he infers, is often the case. I can't personally imagine any situation where maintenance is not important, however. First of all, throw-away programs never seem to be thrown away. I've worked on 20-year-old "throw-away" code. More importantly, my code hits maintenance roughly two seconds after I finish writing it. Whenever I look at code I wrote yesterday, I'm in maintenance mode. I imagine that the writer of that comment is just a much better programmer than me. He writes perfect code right off the bat and never looks back at his code once it's written. Though I can aspire to that level of perfection, I'm not there yet. I'm constantly refactoring my code to improve it. Every time a business rule changes—and this often happens while the program is under construction—the existing code is effectively in maintenance.

Giving up "procedural thinking" isn't easy, but it's worth doing.