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.
And how would the Setter in the second example?
– Woss
nomes._nome = "Ciclano"
i am not setting a new value?– LeAndrade
Leandrade, you are overwriting the method with a string. What happens if you invoke
nomes._nomes()
after makingnomes._nomes = "Ciclano"
?– Andre
@user140828 Cannot access this way, returns error.
– LeAndrade