• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

getter/setter methods

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, again Jacquie. In a separate topic on inheritance, you wrote

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

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.
So (and here's the question, finally) what role do you think get/set methods should have in object oriented systems?
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with that article to the extent that yes, some newbie programmers have a tendency to add getters and setters for every member variable, and this is bad. You shouldn't have getters and setters for every member; indeed, getters and setters don't even need to correspond to individual member variables: they correspond to observable properties of the object, which might be represented by more than one variable internally, or might be computed from other state.
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 ]
 
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I totally agree with Ernest.
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.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A good heuristic from http://c2.com/cgi/wiki?TellDontAsk :


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.

reply
    Bookmark Topic Watch Topic
  • New Topic