11

Possible Duplicate:
Allen Holub wrote “You should never use get/set functions”, is he correct?

Is there a good, no, a very good reason, to go through all the trouble of using getters and setters for object-oriented languages? What's wrong with just using a direct reference to a property or method? Is there some kind of "semantical coverup" that people don't want to talk about in polite company? Was I just too tired and fell asleep when someone walked out and said "Thou Shalt Write Copious Amounts of Code to Obtain Getters and Setters"?

Follow-up after a year:

It seems to be a common occurrence with Java, less so with Python. I'm beginning to wonder if this is more of a cultural phenomena (related to the limitations of the language) rather than "sage advice". As I do not program in Java (currently by choice) I cannot make that assessment.

The current (current being as of this writing 2010-03-22) -1 question score is complete for-the-lulz as far as I am concerned. It's interesting that there are specific questions that are downvoted, not because they are "bad questions", but rather, because they hit someone's raw nerve.

So let's get to the nut of the matter. I repeat myself:

What's wrong with just using a direct reference to a property or method?

And here's the unwritten corollary:

Are we so undisciplined as programmers that we can't keep our hands off of things that are clearly marked "no touchy"?

Community
  • 1
  • 1
Avery Payne
  • 1,738
  • 2
  • 17
  • 31
  • 3
    I don't feel this is an exact duplicate. The other question asks "Should you *never* use getters/setters?" while this question asks "Should you *ever* use getter/setters?" There's a whole character of difference there! – Talljoe Jun 21 '09 at 02:11
  • 3
    D'oh, if this is an exact duplicate, then why the hell didn't it appear in the suggestions when I first posted it? – Avery Payne Jun 21 '09 at 02:19
  • @Talljoe: That is a subtle difference that had escaped me. Sharp eye! I'll be carefully reading all of the other questions in the Related sidebar that answer this question in order to select a more suitable substitute. Thanks. :) – Bill the Lizard Jun 21 '09 at 02:22
  • 2
    @Avery: That's a fair question. I'm not exactly sure what the difference is between the search that gets done when you're asking a question and the one that populates the Related sidebar, but I can see that there is a difference. I typically search from Google before I post a question since it turns up better results. http://www.google.com/coop/cse?cx=018205968162215846785:7n6ajnwyz-i – Bill the Lizard Jun 21 '09 at 02:27
  • 3
    Ugh. If you're having to use something external, then it suggests that the search mechanism probably is broken. I'll try to lodge something on uservoice later. – Avery Payne Jun 21 '09 at 02:33
  • 1
    @Avery: I know this is a bit late, but the list of duplicates shown based on your title when asking is [mostly](http://meta.stackexchange.com/q/42878/54262) [useless](http://meta.stackexchange.com/q/27566/54262). –  Oct 23 '10 at 00:02
  • I found that out the hard way :P but thanks for mentioning it. – Avery Payne Nov 25 '10 at 00:57

5 Answers5

4

Here is Allen Holub (who is brilliant) on the matter. He goes into much more detail on this subject in Holub on Patterns. Some things require public getters and setters like serialization and patterns like the Data Transfer Object pattern. In general, I think necessary evil since your application becomes convoluted when you don't use them.

JP Alioto
  • 44,864
  • 6
  • 88
  • 112
3

Getters and Setters hide your classes data specifics from the users of your classes.

In many cases they are not fully utilized, but it is always a good idea to use them. Direct access to your objects data reduces encapsulation.

If you don't use getters and setters, when you change your mind about a data member, you break your classes interface, and must alter the rest of your codebase to conform to the change. In some cases where your class represents part of a public API this isn't even possible. If you wrap your properties in getters and setters you can make those changes, and hide them from consuming code by modifying the getter and setter methods.

Matthew Vines
  • 27,253
  • 7
  • 76
  • 97
2

Protection. Some properties/methods shouldn't be called from without the class...ever. I'm sure you maintain the sole authority to tell anybody your social security number, right? They have to ask you (getter)? Certainly you wouldn't advise we allow people direct access to private data/methods in our own lifes...why treat your applications any different? :)

Sampson
  • 265,109
  • 74
  • 539
  • 565
  • So...if I'm understanding the gist of this...getters and setters for OO languages that don't have a method to hide their namespace? – Avery Payne Jun 21 '09 at 01:55
  • They build a brick wall around your class, which specific rights to certain items on the inside. Some classes have properties that should not be handled by anybody, ever. These would be defined as private or protected, and as such nobody could manipulate their values from outside of the class. Only by providing a getter can they actually tell what the value is, and only by providing a setter can they actually manipulate the value. You are King of your data - and the only access people have to the inside, is the access you grant them. – Sampson Jun 21 '09 at 02:11
  • 1
    Interesting, more so for the psychology of that explanation than for the explanation itself. I sense another question coming on...but judging on how well the search-for-duplicate-questions feature works (just got closed in less than 30 minutes), I'll have to phrase it carefully. In any case, thanks for the clarification! – Avery Payne Jun 21 '09 at 02:35
  • Good luck :) Hope you find the clarity you seek soon :) – Sampson Jun 21 '09 at 02:41
1

One way that I've found it to be helpful is to be able to set a breakpoint on the set (more so than the get). That probably means "I'm coding it wrong," but at least I can find out exactly when it changes.

Mark Rushakoff
  • 249,864
  • 45
  • 407
  • 398
  • 2
    Actually, I can tell you that it's a function of your debugger. Your debugger (or language, or the engine that drives the language if it's interpretive/semi-compiled/p-code) does not support breaking on the state-change of a property (variable), and you are therefore forced to emulate this behavior. I've been in different languages that do and do-not support this feature, and while it's nice to have, it's not a show-stopper. Still, +1 for (a) at least realizing it's a limitation (b) finding a way around it (c) pointing out a practical use for it, even if it's not a direct answer. – Avery Payne Mar 23 '10 at 02:04
1

Getters and Setters are one aspect of implementing the Open/Close principle. If you encapsulate all of your functionality behind proper properties then code that uses your properties won't break. It also makes it possible to completely replace that object with something else in the future -- espcially if you code to an interface instead of a class.

They are so important that C# went through the trouble to make basic getters and setters easy to write.

To further understand why some aspects of OOD is important, read the book Emergent Design by Scott Bain.

Talljoe
  • 14,593
  • 4
  • 43
  • 39
  • 2
    I'll look into the book. In the meantime, if I'm understanding this at a glance, you're implying that I really, really, don't want to expose more than what's necessary to any other objects...it sounds almost as if all objects should be very tightly encapsulated and everything transacts as if there are millions of little API calls between each object...bah, I'm getting tired, forget that comment. – Avery Payne Jun 21 '09 at 02:15
  • Yes, you've got it precisely! Encapsulation and low coupling. Each object should have its own (single) responsibility and use small, clear interfaces to communicate with any other objects it needs to talk to. – Peeja Dec 02 '11 at 17:13