Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

JavaScript libraries such as jQuery, combine 'getters' and 'setters' in the programming interface for example:

 $('element').css({'color','blue'});

will set the color or

 $('element').css();

will get the css for an element.

Is there a name for such a pattern and is it a good practice to use in applications?

share|improve this question

5 Answers 5

up vote 11 down vote accepted

Martin Fowler recently named it Overloaded getter and setter in this article:

I've been poking around in Javascript recently and one thing that's struck me is the habit of using the same function name for a getter and a setter. So if you want to find out the height of your banner in jQuery you would use $("#banner").height() and if you want to change the height you would use $("#banner").height(100).

This convention is familiar to me, as it was used by Smalltalk. You might get a value with banner height and change it with banner height: 100. Knowing it was a smalltalk convention is enough to expect me to like it, since I have an distant but abiding love for that language. But even the best things have flaws, and I can't hide my dislike for this coding style...

Despite this preference, you do have to follow the conventions of the language you're dealing with. If I were writing Smalltalk again I'd still use height:100 in order retain consistency with the conventions of the language. Javascript, however, isn't noted for having strong conventions, so here I'd prefer to avoid this convention, even if it is used by jQuery...

share|improve this answer
1  
While I typically agree with most of what Fowler says, I disagree with his dislike for this. His reasoning is that JavaScript doesn't have strong conventions like Smalltalk, which makes it usable there. However, jQuery does have strong conventions, and JavaScript is not jQuery. jQuery is a framework. –  CaffGeek Sep 21 '11 at 21:14
    
@Chad, I have to disagree with your reading of that. His argument is that it lacks explicitness and consistency. He says he's use it in Smalltalk because consistency with other trumps his concerns. He's not arguing that Smalltalk's conventions somehow mitigate or eliminate the problem. –  Winston Ewert Sep 21 '11 at 22:36

It's called "method overloading" in OO languages or "function overloading" in non-OO languages.

Whether or not it's good practice is a topic of almost as much debate as getters/setters vs. public members. Those on the pro and con sides probably cut their teeth on languages that had this feature or didn't and are set in their ways. I use it and like the practice for a number of reasons:

  • The context in which it's used pretty well separates one from the other.
  • Prepending get or set to the method name adds verbosity.
  • If there are multiple getters (e.g., one for int and one for double), changing the type in the LHS of an assignment (int x = foo.bar() vs. double x = foo.bar()) doesn't require a code change (barAsInteger() vs. barAsDouble()) to the right side if the class provides both. The down side to this is that sometime it can be difficult to know exactly which method is being called just by looking at the code.
share|improve this answer
    
It's also called "function overloading" in C++. –  DeadMG Sep 21 '11 at 21:50
    
Both terms apply to C++ because it has both methods and bare-naked functions. –  Blrfl Sep 22 '11 at 10:57

Since JavaScript doesn't have actual properties (where setting a value can actually execute code), the patter is one that implements the property idiom. (Even if you call it something else.)

So, in languages implementing real properties, you would do this instead:

element.css = ...
x = element.css

If you were to use the JavaScript pattern in a language that handles properties, you would be doing something abnormal. That would likely not be a good idea. Handle properties the way the language is meant to handle them, so you don't confuse the other people working with you.

share|improve this answer
    
"where setting a value can actually execute code". This isn't actually true anymore. It's been part of the spec since ECMA 5 –  Demian Brecht Sep 21 '11 at 21:03
    
@Demian: But, JQuery works in browsers that don't implement ECMA 5. –  John Fisher Sep 21 '11 at 21:10
    
I didn't mention anything about cross-browser compatibility, just that the quote is incorrect as written. –  Demian Brecht Sep 21 '11 at 21:25
    
@Demian: The text "JavaScript doesn't have actual properties" is correct if you assume that it's using the most commonly available versions of JavaScript. Since we're discussing within a context of JQuery implementation, the statement would be correct. Thanks for pointing out that newer versions of JavaScript have true properties, though. –  John Fisher Sep 22 '11 at 17:02

I think you're looking for properties

share|improve this answer
    
That's the name for the functionality provided in C# (and perhaps other .NET languages?) that is similar to this, but it's not really the same thing. –  Thomas Owens Sep 21 '11 at 20:23
    
Wikipedia agrees though: en.wikipedia.org/wiki/Property_(programming) –  thekip Sep 21 '11 at 20:24
    
Thanks, not really you might have a case say where you set or get a persons salary in an application person.salary('10000') or person.salary() or similar. –  yannis Sep 21 '11 at 20:25
1  
I don't see how. "Properties are read and written like fields", which is not true in the example in the original post. There, explicit method calls are made. It's very similar, but not exactly the same. –  Thomas Owens Sep 21 '11 at 20:25
1  
@yannis This isn't correct. JavaScript has a syntax for properties, and it is not what you described in the original question at all. See en.wikipedia.org/wiki/Property_(programming)#JavaScript for how to implement and use properties in JavaScript. –  Thomas Owens Sep 21 '11 at 20:31

I'm kinda totally against that for a simple reason: A Class, Method or Function should just do one thing -- in my opinion, and combining the getter and setter method will breach that rule. As the result:

  1. The return value of the function varies based on if getter or setter block get executed. This one can simply lead you into a maintainability nightmare. Your method should return only one type of data/object in any case -- or return null, false or throw an exception in case of error.
  2. Writing Unit Tests will be harder as the function is responsible for two totally different functionality.
  3. Writing documentation for such a method or function is harder for obvious reasons.
  4. It won't be consistent when multiple getter methods needed -- as already mentioned in Blrfl answer.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.