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


will set the color or


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?


5 Answers 5


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

  • 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
    Commented Sep 21, 2011 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. Commented Sep 21, 2011 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.
  • It's also called "function overloading" in C++.
    – DeadMG
    Commented Sep 21, 2011 at 21:50
  • Both terms apply to C++ because it has both methods and bare-naked functions.
    – Blrfl
    Commented Sep 22, 2011 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.

  • "where setting a value can actually execute code". This isn't actually true anymore. It's been part of the spec since ECMA 5 Commented Sep 21, 2011 at 21:03
  • @Demian: But, JQuery works in browsers that don't implement ECMA 5. Commented Sep 21, 2011 at 21:10
  • I didn't mention anything about cross-browser compatibility, just that the quote is incorrect as written. Commented Sep 21, 2011 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. Commented Sep 22, 2011 at 17:02
  • "Since JavaScript doesn't have actual properties (where setting a value can actually execute code)" is totally wrong. Javascript has Setters which do exactly this. Perhaps this was added to the standard after the answer was written, I'm not sure, but it is totally wrong now.
    – Inigo
    Commented May 8, 2022 at 20:00

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.

I think you're looking for properties

  • 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
    Commented Sep 21, 2011 at 20:23
  • Wikipedia agrees though: en.wikipedia.org/wiki/Property_(programming)
    – thekip
    Commented Sep 21, 2011 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.
    – yannisl
    Commented Sep 21, 2011 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
    Commented Sep 21, 2011 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
    Commented Sep 21, 2011 at 20:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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