I'm trying to understand what the advantage is, if any, of the following:

const obj = {
    forename: 'Foo',
    surname: 'Bar',
    get name() {
        //yes I get that I can do other stuff here
        return this.forename+' '+this.surname;
    }
}
alert(obj.name); //Foo Bar

...over...

const obj = {
    forename: 'Foo',
    surname: 'Bar',
    name() {
        return this.forename+' '+this.surname;
    }
}
alert(obj.name()); //Foo Bar

I've read around (1; 2; 3) but can't seem to see any benefit beyond readability and code style. Is that all it is? No implicit behavioural changes between the two methods?

Is it with one eye on future class property/method visibility in JavaScript? That would make sense - getters for private properties. But since that's not here yet, I can't see the point of the above.

Can anyone enlighten me?

I'm trying to understand what the advantage is, if any, of the following:

const obj = {
    forename: 'Foo',
    surname: 'Bar',
    get name() {
        //yes I get that I can do other stuff here
        return this.forename+' '+this.surname;
    }
}
alert(obj.name); //Foo Bar

...over...

const obj = {
    forename: 'Foo',
    surname: 'Bar',
    name() {
        return this.forename+' '+this.surname;
    }
}
alert(obj.name()); //Foo Bar

I've read around (1; 2; 3) but can't seem to see any benefit beyond readability and code style. Is that all it is? No implicit behavioural changes between the two methods?

Is it with one eye on future class property/method visibility in JavaScript? That would make sense - getters for private properties. But since that's not here yet, I can't see the point of the above.

Can anyone enlighten me?

• javascript
• oop
• getter-setter
• ecmascript-5

• You can have virtual properties instead of just method calls. Ever used Knockout.JS? It has observable types that you access via a function call (which allows you to subscribe to changes, even to primitives). If you have some long chain of thing, you end up with myViewModel.config().table().header.firstName, for example. You have to remember which of these properties is an observable which isn't and invoke the ones that are. And if you change, say header to be an observable, you need to update all calls to it. – VLAZ Commented Jan 2, 2020 at 19:54
• 1 Private fields are actually already supported on some platforms, e.g. Node 13, I agree that in conjunction with those, getters make more sense – Patrick Hund Commented Jan 2, 2020 at 19:54
• Probably a duplicate of stackoverflow./questions/42342623/… (it even has the same code example). – str Commented Jan 2, 2020 at 20:08
• Thank you, everyone - some great contributions here. As I suspected, it's basically just syntax and readability. I just wanted to be sure I wasn't missing some implicit behavioural differences between the two. – Mitya Commented Jan 3, 2020 at 11:44

4 Answers 4

One difference is typeof will actually work as expected when using a getter, that is, it will return the actual type of the primitive returned by the getter, while using a method will always return function:

const objGetter = {
  forename: 'Foo',
  surname: 'Bar',
  get name() {
    return `${ this.forename } ${ this.surname }`;
  }
}

const objGetterLogic = {
  forename: undefined,
  surname: 'Bar',
  get name() {
    return this.forename ? this.surname : 3;
  }
}


const objMethod = {
  forename: 'Foo',
  surname: 'Bar',
  name() {
    return `${ this.forename } ${ this.surname }`;
  }
}

console.log(`objGetter`, typeof objGetter.name);
console.log(`objMethod`, typeof objMethod.name);
console.log(`objGetterLogic (without forename)`, typeof objGetterLogic.name);

objGetterLogic.forename = 'Alice';

console.log(`objGetterLogic (with forename)`, typeof objGetterLogic.name);

Of course, you can call name() in the version with the method, but with the getter that will work transparently.

Also, if you have nested getters, you can call them transparently, which is something that es in handy if you are navigating an object programmatically, as otherwise, you would need to account for the possibility of properties being either a value or a function that needs to be called to get the actual value you need:

class Shape {  
  constructor(type, children) {
    this.type = type || '';
    this.children = children || [];
  }
  
  get firstChild() {
    return this.children[0];
  }
  
  get lastChild() {
    return this.children[this.children.length - 1];
  }
}

const group1 = new Shape('group1', [
  new Shape('a'),
  new Shape('b'),
  new Shape('c'),
]);

const group2 = new Shape('group2', [
  new Shape('d'),
  new Shape('e'),
  new Shape('f'),
]);

const group4 = new Shape('group4', [
  group1,
  group2,
]);

console.log(group4.firstChild.lastChild.type);

In any case, I think one of the greatest advantages of getters and setters are just increased readability and reduced verbosity, even though that usually es down to personal preference anyway. In any case, I rather use:

person.name = 'Alice Smith';

Than:

person.setName('Alice', 'Smith');

But we could also argue the latter might be more appropriate in some cases.

Since you defined just a getter for name, without defining a setter, if you attempt to change its value, for example obj.name = "foo", nothing is going to happen.

On the other hand, if you try to change your name property on your second object, nothing will stop you by doing so.

Since the capabilities of these two features are identical, we need to consider the readability and writeability of code that interacts with such a property (or method).

The entire advantage is the ability to run functions when accessing a property. "Ah," you say, "but if I wanted to run a function, I'd just use a function." And you'd be correct -- as I say initially -- that the two have no difference in terms of capabilities. But accessing a property is different from calling a function for the person writing code that interacts with your object.

Sylistically, I expect accessor methods to have names that start with get. Your example function called name seems poor style to me, whereas a property called name seems much better. If you ask me what advantage obj.getName() has over obj.name I can readily tell you the latter is much shorter to type! There are corresponding readability concerns with setters: obj.setBirthday(new Date(...)) versus a setter property, obj.birthday = new Date(...) (suppose, e.g., that this mutates a corresponding age property)

That's it -- all languages are designed to make a Turing-plete set of functionality more prehensible to human authors and readers. If a feature doesn't help you achieve that goal, don't use it!

1. As a syntactic sugar it can be useful to make your code if not more readable then at least less clogged: x = a().b().c().d() vs x = a.b.c.d
2. Suppose you already have a code like that obj.attr... a lot of code like that, and at some point you realize that you need a function instead of access operator in all these places Get/set to the rescue. Especially useful in debug to catch a property access. And even more so if you have to work with code you have no control over
3. Sometimes using getter is more idiomatic. Reader expects that obj.attr has no side effects, but he is not so sure if he sees a function