Welcome to the Treehouse Community

The Treehouse Community is a meeting place for developers, designers, and programmers of all backgrounds and skill levels to get support. Collaborate here on code errors or bugs that you need feedback on, or asking for an extra set of eyes on your latest project. Join thousands of Treehouse students and alumni in the community today. (Note: Only Treehouse students can comment or ask questions, but non-students are welcome to browse our conversations.)

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and a supportive community. Start your free trial today.

JavaScript Object-Oriented JavaScript Getters and Setters Setters

Why use the same name as the property?

I understand this is shorthand for Object.defineProperty I believe. I do see the benefit of this way however, I do not see the reasoning for using set owner when it really is just a function. Should it not be named set changeOwner that way you do not need the getter function and the original property named owner can be accessed using dot notation?

An example: set changeOwner(owner) { this.owner = owner; }

2 Answers

Eric M
Eric M
11,517 Points

Hi Justin,

You've got a few questions in there, I'm going to focus on the last one "Should it not be named set changeOwner that way you do not need the getter function and the original property named owner can be accessed using dot notation?" and write a little about getters vs direct property access. (Feel free to reword the question if I've missed the mark on what you're trying to figure out.)

Without saying whether or not one style is better than the other (it will depend on the project and other factors) one of the principles of object oriented design is encapsulation. Encapsulation is a broad concept so I'm not going to cover it fully, but sometimes we want to restrict direct access to a member (e.g. owner) but have a getter return details about it.

It's not going to be necessary in every piece of code or made fully necessary in every example, but it's a worthwhile pattern to be able to recognise because it's very common. Especially in more strictly OOP languages.

For instance, say I have a large and complex Business Intelligence dashboard that executives look at to make decisions. We're a big company though, so I have some execs in the USA and some in China. A very small part of this dashboard program is a temperature display, maybe we're in food manufacturing and we want to chart how much more ice cream we sell as the temperature rises.

There's separate data science teams in the USA and China preparing these dashboards, and they're really more data people than programmers, so I don't want to expose everything to them. Moreover, USA uses Fahrenheit and China uses Celsius, and we need to be able both store the temperature for an hour in a region, and return that temperature using a common interface. Storing both a Celsius and Fahrenheit temperature would violate DRY and just feels clumsy.

Let's just say the China team wants to get the temperature for right now, we want to them to be able to call region.getTemperature(). we store our region.temperature value as a float using the Kelvin temperature scale. This allows us to within the getTemperature method check the local temperature scale setting and covert from Kelvin to the local scale (in this case Celsius for the China team). The USA team can also call the same method, and their dashboards will show the temperature in Fahrenheit.

If they were accessing region.temperature directly would they know it was in Kelvin? This is one (imperfect) example, but I hope it helps explain why these patterns get used.

To make the example a little more realistic we could say our object for each of our sales region manages querying a DB table where historical temperature data is stored and at a point in time we want the program to be able to find the temperature via a trusted weather API and run region.setTemperature(temp, datetime, tempScale) to store in the DB and have our data teams run region.getTemperature(datetime) to get historical temperature data, but that doesn't really add anything to the encapsulation example.

Ashley Boucher
Ashley Boucher
Treehouse Teacher

Hi Eric, this is a really excellent explanation. Thank you!

Hey everyone thanks! I rewatched the video, reread the MSDN and reflected. I know believe I understand. Thank you again so much for your explanation!