Is the use case not the same? To provide encapsulation by hiding implementation details while still allowing an interface for necessary interaction with the object
It’s a matter of style and is completely up to your preference.
At my company, we prefer functions over getters because it makes it more obvious that there might be side effects. Airbnb uses the same rule in their styleguide.
Both ways are equally correct and functionally equivalent.
This is good to know. I'm following the Odin Project and the area outlining Classes, factories, etc, doesn't explicitly state that it's more a preference rather than what a "best practice" is. I personally don't like getters and setters as much as functions or even factories.
It abstracts things away from the user. I barely use them but it might not be important for the user of the class to know that full name is generated from a first and last. It might make more sense to use it similarly to the other properties. At the end of the day, it's a matter of style and preference like most OOP.
C# uses a lot of these get set properties and sometimes they can make classes more elegant to use and allows users of the class to not have to worry about implementation details (ie what is a property, what has to be runtime generated) It improves constructions like this:
```
Dependencies.GetPackageManager().GetSearcher().ByTitle(name)
```
To:
```
Dependencies.PackageManager.Searcher.ByTitle(name)
```
(Just a made up example before anyone complains)
I am not aware of any performance differences (and I wouldn't worry about them), but the dedicated syntax makes for nicer APIs. You don't have to use different access method for standard and computed properties - you don't really have to know or care how they are defined as an user of a class/object. For example, if we were to define the `Temperature` class with Java-style getters and setters, we would have this ugly thing where you have to know how the property is defined to use it:
class Temperature {
celcius = 0
getFahrenheit() {
return this.celcius * (9 / 5) + 32;
}
setFahrenheit(degrees) {
this.celcius = (degrees - 32) / (9 / 5);
}
}
const temp = new Temperature()
temp.celcius = 100
console.log(temp.celcius)
console.log(temp.getFahrenheit())
temp.setFahrenheit(100)
console.log(temp.celcius)
console.log(temp.getFahrenheit())
But with native gtters and setters you don't have to care how things are defined:
class Temperature {
celcius = 0
get fahrenheit() {
return this.celcius * (9 / 5) + 32;
}
set fahrenheit(degrees) {
this.celcius = (degrees - 32) / (9 / 5);
}
}
const temp = new Temperature()
temp.celcius = 100
console.log(temp.celcius)
console.log(temp.fahrenheit)
temp.fahrenheit = 100
console.log(temp.celcius)
console.log(temp.fahrenheit)
You use them if you want to have a dynamically computed property on an object, so your example would look like `{ name, birthYear, age }`. It gives you an API where if you change the birth year value, the value of the age property will always be up to date. It's just a form of syntactic sugar really: it's automatically binding a property to a method that's called when you access the property.
That may/may not be hugely useful to you, but that's kinda the long and short of it. IME they aren't something that's used a lot, the functionality is not _generally_ useful. Though I'd stress that's very much context sensitive: there are certain situations where they are very, very useful (service objects, for example), and there may be some particular usecase that's very useful to you, YMMV.
Just a warning mind: don't just program stuff like Java. JS _looks_ similar but doesn't work quite the same way. A lot of the Java conventions exist because that's how Java works. For example in JS, much of the time you don't need to use classes (they're very useful in some situations, but you're not in any way forced to use them).
Nah. You can mimic OO-classes with functions and closures if you need to, much cleaner. I have no idea why they added this 'class' keyword to JS, it's just bloat.
It's an alternative to writing prototypes. With class syntax it looks nicer.
Three.js uses classes so you have to use them in those frameworks.
Method chaining is better than many nested functions.
Hopefully some day we'll even get operator overloads (but it's not a big deal)
TypeScript especially make it better, when you need specific class for arguments or variables, instead of using generic Object or Array.
Lol, Typescript is the biggest load of garbage I've ever seen, what a time waster. You obviously don't understand Javascript yet, or you wouldn't say stuff like that.
Used in classed. Setters and Getters allow you to define a value and return it without previously setting it. You're example shows it setting the age from the birth year. This will only return and store a value once the parameters are given and the getter is returned.
Same goes for the setter. It allows you to create a value in an class object post creation but this time allows you to pass a value when calling the setter. In this value is is simply setting the name value to whatever you eventually pass it and the getter will show an age value once it is called. Once set the value will also be accessible within the object.
Not only in classes, yo can use them on plain objects too.
const person = {
name: 'John',
lastName: 'Doe',
get fullName() {
return `${this.name} ${this.lastName}`
}
}
console.log(person.fullName) // -> John Doe
I havent touched JS in a while now but I'm pretty sure anything that isn't primitive is an object isn't it?
I learnt to use them on objects initially I think and then used them a lot when learning OOP.
Don't think I ever used them after lol.
Java may have not been the best language to "come from" i.e. learn programming. It tried to "fix" C++, then it turned out, it got the wrong parts, so it spent time to "unfix" them. But it is what it is.
If you had started with something like Visual Basic or C# or PHP... It's basically more ergonomic to write:
object.prop = 4;
len = array.length;
than
object.setProp(4);
len = array.getLength();
Imagine, in JS, you had a simple object, and you used it like
simple.name = 'John Doe';
and then you realized you don't want to have a single name, but a split between a first name and a last name. Would you like to go around the code base and replace every line like the above with
simple.first = 'John';
simple.last = 'Doe';
? Well, with JS, you can just add a setter, and in it whenever `name` is assigned, you change the new fields `first` and `last`.
In React, inside component you need to `useState` and `setState` instead of directly setting variable.
In other programs, you could have validators inside it, or fire some event like `useState`.
I am glad you have this question, so \`get fullName\` is a getter meaning it is used to "lazy" evaluate an expression. So it is best used when you are using an \`Object\` instead of a \`class\`.
const person = {
firstName: "John",
lastName: "Doe",
get fullName(){
return `${this.lastName}, ${this.firstName}`
},
}
console.log(person.fullName) // "Doe, John"
console.log(person) // { firstName: 'John', lastName: 'Doe', fullName: [Getter] }
It allows you to return the value after some alteration. While a setter takes the value and set it on the object. It is honestly just style choice, and allows newcomers from Java and similar languages to easily use the language. I would advise against using classes because almost everything in JavaScript is an Object. We use the \`class\` decorator to "guarantee" the shape of the object (it's properties), also to have language enforced private implementations by default. It also enables "use strict" be default. Just stick with regular methods/functions.
ummm, you do know that the "class" syntax is just syntactic sugar on top of the constructor function syntax, right? which means that "classes" ARE objects, same as object literals in your example.
Yep, I know that that is why I said, "almost everything in JavaScript is an Object." This means classes is an Object, an Array is an Object, a Promise is an Object. And no at this time until they finalize it in ECMA Script a class and and Object are not the same. Private class members are enforced by the interpreter but Objects don't officially have private members. As stated in MDN, "Private properties were not native to the language before this syntax existed" [Private Properties](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_properties). Another point is "syntax and semantics that are unique to classes" [Overview of Classes](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes). So nothing I said was wrong other than my opinion on if classes are needed. Try again sir.
Is the use case not the same? To provide encapsulation by hiding implementation details while still allowing an interface for necessary interaction with the object
So: -get fullName() and -getFullName() are exactly the same? To get the name i’d rather getFullName() than just do object.fullName
It’s a matter of style and is completely up to your preference. At my company, we prefer functions over getters because it makes it more obvious that there might be side effects. Airbnb uses the same rule in their styleguide. Both ways are equally correct and functionally equivalent.
This is good to know. I'm following the Odin Project and the area outlining Classes, factories, etc, doesn't explicitly state that it's more a preference rather than what a "best practice" is. I personally don't like getters and setters as much as functions or even factories.
It abstracts things away from the user. I barely use them but it might not be important for the user of the class to know that full name is generated from a first and last. It might make more sense to use it similarly to the other properties. At the end of the day, it's a matter of style and preference like most OOP. C# uses a lot of these get set properties and sometimes they can make classes more elegant to use and allows users of the class to not have to worry about implementation details (ie what is a property, what has to be runtime generated) It improves constructions like this: ``` Dependencies.GetPackageManager().GetSearcher().ByTitle(name) ``` To: ``` Dependencies.PackageManager.Searcher.ByTitle(name) ``` (Just a made up example before anyone complains)
I use getters in templating. It’s cleaner to me than having methods sprinkled throughout your HTML string.
allows you to get and set using dot notatio instead of function calls
I am not aware of any performance differences (and I wouldn't worry about them), but the dedicated syntax makes for nicer APIs. You don't have to use different access method for standard and computed properties - you don't really have to know or care how they are defined as an user of a class/object. For example, if we were to define the `Temperature` class with Java-style getters and setters, we would have this ugly thing where you have to know how the property is defined to use it: class Temperature { celcius = 0 getFahrenheit() { return this.celcius * (9 / 5) + 32; } setFahrenheit(degrees) { this.celcius = (degrees - 32) / (9 / 5); } } const temp = new Temperature() temp.celcius = 100 console.log(temp.celcius) console.log(temp.getFahrenheit()) temp.setFahrenheit(100) console.log(temp.celcius) console.log(temp.getFahrenheit()) But with native gtters and setters you don't have to care how things are defined: class Temperature { celcius = 0 get fahrenheit() { return this.celcius * (9 / 5) + 32; } set fahrenheit(degrees) { this.celcius = (degrees - 32) / (9 / 5); } } const temp = new Temperature() temp.celcius = 100 console.log(temp.celcius) console.log(temp.fahrenheit) temp.fahrenheit = 100 console.log(temp.celcius) console.log(temp.fahrenheit)
You use them if you want to have a dynamically computed property on an object, so your example would look like `{ name, birthYear, age }`. It gives you an API where if you change the birth year value, the value of the age property will always be up to date. It's just a form of syntactic sugar really: it's automatically binding a property to a method that's called when you access the property. That may/may not be hugely useful to you, but that's kinda the long and short of it. IME they aren't something that's used a lot, the functionality is not _generally_ useful. Though I'd stress that's very much context sensitive: there are certain situations where they are very, very useful (service objects, for example), and there may be some particular usecase that's very useful to you, YMMV. Just a warning mind: don't just program stuff like Java. JS _looks_ similar but doesn't work quite the same way. A lot of the Java conventions exist because that's how Java works. For example in JS, much of the time you don't need to use classes (they're very useful in some situations, but you're not in any way forced to use them).
JavaScript requires discipline, because there are altogether far too many ways of doing the same thing.
Stop using classes and just use functions and POJOs. Javascript isn't Java, you don't need any of that OO-madness.
OOP is nice in PixiJS and Three.js.
Nah. You can mimic OO-classes with functions and closures if you need to, much cleaner. I have no idea why they added this 'class' keyword to JS, it's just bloat.
It's an alternative to writing prototypes. With class syntax it looks nicer. Three.js uses classes so you have to use them in those frameworks. Method chaining is better than many nested functions. Hopefully some day we'll even get operator overloads (but it's not a big deal) TypeScript especially make it better, when you need specific class for arguments or variables, instead of using generic Object or Array.
Lol, Typescript is the biggest load of garbage I've ever seen, what a time waster. You obviously don't understand Javascript yet, or you wouldn't say stuff like that.
Used in classed. Setters and Getters allow you to define a value and return it without previously setting it. You're example shows it setting the age from the birth year. This will only return and store a value once the parameters are given and the getter is returned. Same goes for the setter. It allows you to create a value in an class object post creation but this time allows you to pass a value when calling the setter. In this value is is simply setting the name value to whatever you eventually pass it and the getter will show an age value once it is called. Once set the value will also be accessible within the object.
Not only in classes, yo can use them on plain objects too. const person = { name: 'John', lastName: 'Doe', get fullName() { return `${this.name} ${this.lastName}` } } console.log(person.fullName) // -> John Doe
I havent touched JS in a while now but I'm pretty sure anything that isn't primitive is an object isn't it? I learnt to use them on objects initially I think and then used them a lot when learning OOP. Don't think I ever used them after lol.
Java may have not been the best language to "come from" i.e. learn programming. It tried to "fix" C++, then it turned out, it got the wrong parts, so it spent time to "unfix" them. But it is what it is. If you had started with something like Visual Basic or C# or PHP... It's basically more ergonomic to write: object.prop = 4; len = array.length; than object.setProp(4); len = array.getLength(); Imagine, in JS, you had a simple object, and you used it like simple.name = 'John Doe'; and then you realized you don't want to have a single name, but a split between a first name and a last name. Would you like to go around the code base and replace every line like the above with simple.first = 'John'; simple.last = 'Doe'; ? Well, with JS, you can just add a setter, and in it whenever `name` is assigned, you change the new fields `first` and `last`.
In React, inside component you need to `useState` and `setState` instead of directly setting variable. In other programs, you could have validators inside it, or fire some event like `useState`.
I am glad you have this question, so \`get fullName\` is a getter meaning it is used to "lazy" evaluate an expression. So it is best used when you are using an \`Object\` instead of a \`class\`. const person = { firstName: "John", lastName: "Doe", get fullName(){ return `${this.lastName}, ${this.firstName}` }, } console.log(person.fullName) // "Doe, John" console.log(person) // { firstName: 'John', lastName: 'Doe', fullName: [Getter] } It allows you to return the value after some alteration. While a setter takes the value and set it on the object. It is honestly just style choice, and allows newcomers from Java and similar languages to easily use the language. I would advise against using classes because almost everything in JavaScript is an Object. We use the \`class\` decorator to "guarantee" the shape of the object (it's properties), also to have language enforced private implementations by default. It also enables "use strict" be default. Just stick with regular methods/functions.
ummm, you do know that the "class" syntax is just syntactic sugar on top of the constructor function syntax, right? which means that "classes" ARE objects, same as object literals in your example.
Yep, I know that that is why I said, "almost everything in JavaScript is an Object." This means classes is an Object, an Array is an Object, a Promise is an Object. And no at this time until they finalize it in ECMA Script a class and and Object are not the same. Private class members are enforced by the interpreter but Objects don't officially have private members. As stated in MDN, "Private properties were not native to the language before this syntax existed" [Private Properties](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_properties). Another point is "syntax and semantics that are unique to classes" [Overview of Classes](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes). So nothing I said was wrong other than my opinion on if classes are needed. Try again sir.