Combining getters and setters

Question

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?

Answer 1

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...

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

I think you're looking for properties