The big idea here is that getters and setters enforce separation between the user’s interaction with the object and the internal structure of the object. This means that you are free to modify and improve the internal structure of your objects without those changes causing far reaching changes throughout your codebase.
I agree and I didn’t intend to suggest a change, I was just complaining about something that always bugged me.
Yes but the point is not the conversion. You’re not building a converter tool. The end user who uses the getter and setter methods never gets in touch with Fahrenheit, they couldn’t use this as a conversion tool Celsius->Fahrenheit or vice versa, even if they wanted to.
I’m not sure what you mean by “installing the formula” but if you’d like to discuss your code, it would help to see your code…
And T is just short for temperature.
this.Faren= 5/9 * (Fahrenheit - 32)
Just the getter I used…the setter I took out because I didn’t “need it”
… you most certainly need a setter of some sort
But then I don’t understand…the way I see API is you’re pretty much communicating with the server using an interface, you insert a value within Fahrenheit and it returns in Celsius. One would install the formula onto the server?
Then I don’t understand what this exercise it trying to put across
You are missing the point of this challenge. The point is to introduce the getter and setter methods because they are a part of JS and you may run into them. Just to be clear, you don’t have to use getters and setters, in fact some people will argue that they are a bad idea. But because they are a part of JS then you should be familiar with them and that is the whole point of this challenge, nothing else.
So it doesn’t make any sense to be arguing over whether you should use one or two formulas or whether you need to use a getter or setter in the first place because that’s not the point of this challenge.
Does that make sense?
An API is the functions/properties exposed by a program or a piece of code through which a user interacts with it (user can just be yourself, with program being a few lines of code). It doesn’t have anything to do with servers.
There is a piece of code that creates an object. That object can be interacted with via a getter and a setter: those two are the API
and what happens when you want to set a new temperature for the thermostat?
oh okey, then I’m completely missing the point of getters/setters, I thought it was a conversion tool, well that’s how I understood it to be…
A getter lets the person who wants to use your object to get a value. A setter lets the person who wants to use your object to set a value.
The getter and setter functions help control which values the user can get/set and can also provide validity checks to make sure they cannot set garbage values.
Also, getters/setters provide encapsulation, separating the user interface from internal design decisions.
Nope, they are just another way to get a value and set a value. In the old days, if you were storing a value internally in a class (such as
temp) and wanted people to have access to it you would create a method called
getTemp() to retrieve the value and
setTemp(t) to set the value. The getter and setter syntax just offers you a different way to do that. That’s it.
You fill it in at the “new” object (I’ve just taken a piece of my code from the top to illustrate that I took setter out and put formula in the constructor property), it’s what I did and it works in the editor (so instead of 76, I put a random number in and it changes the editor value
But I’m actually going to go through getters and setters again…going to research it a bit more, seems I’ve “missed the boat” here
This conversation doesn’t seem to be effective. Rather than us keeping repeating the same thing, perhaps getting some other perspectives might help. I might suggest going to youtube and looking for “getters and setters” and see some other examples and explanations.
The other option is to just not worry about it too much - you may not need it much (depending on your coding paradigm) and you can figure it out later rather than spending all this time on this one tiny topic.
But I’ve explained it as best as I can so I’m out … best of luck.
you are creating a new thermostat in that way, not updating the existing one
By giving a new value to Fahrenheit?
Completely replacing the object with a brand new object is very different than updating a value stored in the object.
Yeah the server needs to be able to convert Fahrenheit and Celsius internally. Each time you write this:
const thermos1 = new Thermostat(76) const thermos2 = new Thermostat(84) const thermos3 = new Thermostat(101)
…you’re creating a new server. If you want to either read (get) or change (set) the temperature of a certain server, you need a getter and a setter function.
Of course you can create new thermostats left and right as much as you wish, but the point is to create one thermostat and then interact with that one thermostat through getters and setters.