62

I know how getter and setter work in JavaScript. What I don't understand is why we need them when we can get the same result using normal functions? Consider the following code:

var person = {
    firstName: 'Jimmy',
    lastName: 'Smith',
    get fullName() {
        return this.firstName + ' ' + this.lastName;
    }
}

console.log(person.fullName);    // Jimmy Smith

We can easily replace getter with a function:

var person = {
    firstName: 'Jimmy',
    lastName: 'Smith',
    fullName: function() {
        return this.firstName + ' ' + this.lastName;
    }
}

console.log(person.fullName());    // Jimmy Smith

I don't see the point of writing getter and setter.

NL500
  • 987
  • 2
  • 8
  • 13
  • your question is about which is better?, or how do it? – Álvaro Touzón Feb 20 '17 at 10:54
  • 7
    I think it is just a "style" matter, as you don't "need" to use them, you "can" use them, if you wish – Igino Boffa Feb 20 '17 at 10:55
  • 2
    check [this](http://stackoverflow.com/a/28222366/2545680) and [this](http://stackoverflow.com/questions/1568091/why-use-getters-and-setters) – Max Koretskyi Feb 20 '17 at 10:56
  • It can make some code easier if you know you can treat everything as a property, e.g. `get(obj, 'path.to.nested.property')` (resolving a property value from a string representation). – deceze Feb 20 '17 at 10:56
  • here is the same question that you are asking [http://stackoverflow.com/questions/1568091/why-use-getters-and-setters](http://stackoverflow.com/questions/1568091/why-use-getters-and-setters) – Kishan Oza Feb 20 '17 at 10:58
  • 2
    Arguably it can make code more readable: `foo.status = 'inactive'` vs. `foo.setStatus('inactive')`… – deceze Feb 20 '17 at 11:00
  • 23
    This is not an opinion based question. It is completely valid and relates to accessibility of private variables. I was about to provide a completely valid answer. – Inkdot Feb 20 '17 at 11:05
  • 1
    Well, for those interested, getters and setters are a method of allowing accessibility of private variables inside a function. This ensures a user cannot get or set the variable unless they use the defined getter/setter methods. – Inkdot Feb 20 '17 at 11:07
  • 3
    @Inkdot The question is why to use `.foo` instead of `.getFoo()`/`.setFoo()`; they both achieve the same thing WRT encapsulation. – deceze Feb 20 '17 at 11:09
  • 1
    @KishanOza: it's not really the same question. The one you linked to asks about using accessors instead of public fields. This one is about using accessors instead of methods. – Dan Dascalescu Apr 07 '19 at 19:14

1 Answers1

41

A difference between using a getter or setter and using a standard function is that getters/setters are automatically invoked on assignment. So it looks just like a normal property but behind the scenes you can have extra logic (or checks) to be run just before or after the assignment.

So if you decide to add this kind of extra logic to one of the existing object properties that is already being referenced, you can convert it to getter/setter style without altering the rest of the code that has access to that property.

Edit: Here is an example for an extra logic, this class counts how many times its name is read:

class MyClass {
  constructor() {
    this.refCount = 0;
    this._name = 'the class';
  }

  get name() {
    this.refCount++;
    console.log(`name is read ${this.refCount} times.`);
    return this._name;
  }
}

const myClass = new MyClass();

let maxMessages = 5;
const t = setInterval(() => {
  console.log(`name: ${myClass.name}`);
  
  if (--maxMessages < 1) {
    console.log('done');
    clearInterval(t);
  }
}, 1000);
Bulent Vural
  • 2,390
  • 1
  • 12
  • 16
  • 7
    And the question is why `foo.bar = baz` using a setter is any better than `foo.setBar(baz)`… – deceze Feb 20 '17 at 10:59
  • The question was slightly different than what you understand anyway, added a second paragraph to clarify the benefit. – Bulent Vural Feb 20 '17 at 11:05
  • 2
    Assuming you're designing an interface from the beginning to use getters/setters instead of retrofitting it… what's your answer then? – deceze Feb 20 '17 at 11:07
  • That's what the second paragraph explains. – Bulent Vural Feb 20 '17 at 11:10
  • 6
    No, it doesn't. I'm saying I'm writing a new object today which does not have any references yet, and I'm opting to write `get foo()`/`set foo()` instead of `getFoo()`/`setFoo()`… why would I? – deceze Feb 20 '17 at 11:12
  • 7
    You cannot use the assignments like myObj.foo = 'some data' with getFoo, setFoo. You always need to call those functions. And if you change your mind later, say to add extra logic, you need to convert all references to function calls. – Bulent Vural Feb 20 '17 at 11:19
  • @BulentVural And what do you mean by extra logic. Can you give an example? Then it would be easy to understand. – the_haystacker May 06 '20 at 10:05
  • Added an example. – Bulent Vural May 07 '20 at 11:39