What is the advantage of using getters/setters in Javascript classes?

Asked

Viewed 731 times

11

For example in this code below I use methods getters and setters in class:

class Pessoa {
  constructor(nome) {
    this.nomePessoa = nome;
  }
  get _nomes() {
    return this.nomePessoa;
  }
  set _nomes(valor) {
    this.nomePessoa = valor;
  }
}

const nomes = new Pessoa("Fulano");
console.log(nomes._nomes);                         // Fulano

nomes._nomes = "Ciclano";
console.log(nomes._nomes);                         // Ciclano

The program returns the data correctly, however, I can get the same results with a much simpler syntax:

class Pessoa {
  constructor(nome) {
    this.nomePessoa = nome;
  }
  _nomes() {
    return this.nomePessoa;
  }
}

const nomes = new Pessoa("Fulano");
console.log(nomes._nomes());                       // Fulano

nomes._nomes = "Ciclano";
console.log(nomes._nomes);                         // Ciclano

  • What would be the real use of methods getters/setters in Javascript classes?
  • There is some advantage in using them, if they are necessary?
  • And how would the Setter in the second example?

  • nomes._nome = "Ciclano" i am not setting a new value?

  • 1

    Leandrade, you are overwriting the method with a string. What happens if you invoke nomes._nomes() after making nomes._nomes = "Ciclano"?

  • @user140828 Cannot access this way, returns error.

3 answers

11


General advantages

The advantage is more or less the same as the use in other languages from the conceptual point of view, since it is necessary to do something relevant there, which does not have in the example.

The design pattern getter and Setter is a way to access an object state through a method that takes the value of a field or modifies its value.

If you do this you can perform some things instead of simply accessing the state, then the getter may not give the gross value of a field, but rather something calculated using zero, one or more fields to obtain the result, so it need not be bound to a specific field. A Setter can manipulate the received value before saving to a field, or at least validate whether the received value is within the expected.

In general this pattern is done with normal methods. Some languages provide a syntax that causes these methods to get confused with access to the field, such as Javascript, and that’s what you’re talking about. In this way it is possible to make these methods pass as if they were fields (which people wrongly call attributes), but it’s a syntax trick.

Some people don’t like this because it hides some logic behind something that seems to be a simple access or assignment to a variable. But if this execution is implementation detail then it does not matter, who consumes should not even know.

One advantage that these languages give is that you can start using the field normally and then switch to a getter and Setter without changing anything in the syntax, so it is transparent a change, you do not need to create this pattern in advance.

In other languages it may be useful to already create this pattern of getter/Setter even if you won’t use it because if you need to implement some logic one day you already have the method syntax and not the field. In JS you don’t need to do this because the syntax of the getter/Setter is the same. Example of language you need is Java. That’s why Java can benefit more from using these methods even if they do nothing, if one day it changes, you don’t have to change consumer codes.

Other languages have syntax equal to JS, but they have Binding* anticipated, so even if you don’t need a syntax change if you go from a field to a getter/Setter need to recompile the whole code again for it to make a new Binding and so the code called refer to the new form now with transparent methods being called to do the get and the set. Example is C#. If you change a consumer code from a call to the field to a call to the method, fine with the syntax, the problem is that if the consumer code is compiled in a different cycle from the code of your class that had a field change to method getter/Setter (even with field syntax like in C# or JS), consumer code will only know this when it is recompiled by looking at the new class.

"Advantage" to use getter/Setter that adds nothing

In JS there is no compilation, the Binding is done on the run, so even that’s not a problem for her. If you’re asking if you should use getter/Setter every time even if it has no logic at all, then, no, in JS it has no advantage. The advantage is given when you have some logic in the accessor or modifier, so some algorithm running is in the getter, either in the Setter.

Use the simple syntax until you need something more complicated.

But of course, if you ever find a compiled JS implementation, you have to think about it. Your class will be consumed by your team and you can ensure that their consumer code will always be recompiled if the class changes as well, but if it is used by a third party, if you can’t control when the consumer code is recompiled, then you could be in trouble. But let’s not be sure, it will depend on how it is implemented in this hypothetical implementation of Javasrript.

Some people use the getter/Setter even if they didn’t have to because they read somewhere that they’re meant to do and how they didn’t learn to program but to follow cake recipes that they don’t understand they do things that make no sense and harm their own code. Some people only do it because the team is managed by someone like that who forces them to do it.


*The moment the actual code is effectively linked to the call. In compiled languages it is usually the time of compilation (in some cases it may be at the time of the linking (in some cases moment of charge) or even the Jiter of the code, but don’t assume anything, each implementation is one way. In interpreted languages, unless you have some optimization or something in the specification that says something different, the link is always at the moment you will run, then any change in a part of what is being run to run the application is already noticed by the entire application, unless you use some specific trick.

  • Perfect man, but once quite enlightening.

  • The negative must have been given because someone who has learned that the cake recipe should always be followed.

  • Most likely :)

6

It is more a matter of opinion. I believe that the most common current of opinion discourages the use of such a form of statement, some reasons include:

  • Code readability, nonexplicit code (an access to a property is actually calling a function);
  • It is more complicated to overwrite the function (you will have to use one of the javascript’s object base methods);
  • Optimization of packers. Javascript code packers (webpack, rollup) use logic to determine whether or not a code section is used and remove it from the final compilation. The use of getters and setters can prevent the marking of a code section for removal (the bundler has no way of knowing if that code is accessed because it can generate "side-effects").

You can see the frequent use of these features in the DOM API itself, for example when writing window.location.href = 'xxx' You’re actually invoking a Setter. It may even be useful in refactor cases but it really gets more at your discretion and the problem you need to solve.

  • Good explanation, really is to think of the use. Thank you for responding.

2

First: Why use Getters and Setters?

They are used if other objects need access to the attributes, the object provides public operations (known as getters and setters) to manipulate these attributes. That is, a way to access your attributes in a class that is private and encapsulated.

Getters is known as Accessor and Setters as Mutator, both are in the standardization of Ecmascript. Example of use: https://www.w3schools.com/js/js_object_accessors.asp

So it’s not the question of being something just relevant, it’s how you take values of attributes in POO following the standardization.

What is the advantage? - maybe some already do this and do not even know that you are using Accessors or Mutator, that is nothing more than taking values and assigning values of a class as explained, however, encapsulated.

It is the practice of the POO, in accessing the variables of an object, it is not a matter of advantage, or being a super project, it is nothing more than the correct way of doing. As already mentioned, is in the standard established by Javascript and who search will see that is a POO pattern.

Regardless of the language this is the concept and the reason to be used, now how will be used each language has the correct way to do.

Exemplo: getter
     
// Create an object:

var person = {
  firstName: "John",
  lastName : "Doe",
  language : "en",
  get lang() {
    return this.language;
  }
};

// Display data from the object using a getter:
document.getElementById("demo").innerHTML = person.lang;


Exemplo: setters

  var person = {
  firstName: "John",
  lastName : "Doe",
  language : "",
  set lang(lang) {
    this.language = lang;
  }
};

// Set an object property using a setter:
person.lang = "en";

// Display data from the object:
document.getElementById("demo").innerHTML = person.language;

Browser other questions tagged

You are not signed in. Login or sign up in order to post.