and then followed that with a code sample. Recently, I read an interesting article from Allen Holub called Why getter and setter methods are evil in which he claims that too many of these impact a systems maintainability by exposing implementation details.
If a parent class has a private data member but public get/set methods for that member, then the subclass can use the inherited get/set methods to access its own private attributes
So (and here's the question, finally) what role do you think get/set methods should have in object oriented systems?
But his essential thesis in that article is that an object having any observable properties at all is just bad design -- and that's just hyperbole to sell newspapers. Use getters and setters when you need to, but don't if you don't.
If you've got a Person object, Alan's argument says that it can't have a getAge() method, only a displayAge(DisplaySubstrate) method. That's just silly. Sells papers, though.
[ October 17, 2003: Message edited by: Ernest Friedman-Hill ]
It's a bit irresponsible to call "getters and setters evil". Especially when he says later:
"Design, by nature, is a series of trade-offs. Every choice has a good and bad side, and you make your choice in the context of overall criteria defined by necessity. Good and bad are not absolutes, however. A good decision in one context might be bad in another."
I think the last quote is the most important one to remember from the article.
Very short summary: It is okay to use accessors to get the state of an object, as long as you don't use the result to make decisions outside the object. Any decisions based upon the state of an object, should be made inside the object itself.