Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial
Justin Duncan
8,465 PointsWhy 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 ownerwhen 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; }
3 Answers
andren
28,558 PointsYour question is not attached to any lecture so I don't really have any idea what exactly the code you are asking about looked like. But I can say that generally speaking the point of using a Getter/Setter pattern is precisely so that you can't access the property directly with dot notation. That is considered a feature, not a problem.
It is an example of a concept called Encapsulation which is considered to be a fundamental concept within Object Oriented Programming. If it is possible for outside code to directly read and write the property of an object then that object has no real control over the property, and that can be pretty bad from a stability and consistency standpoint.
By forcing outside code to interface with the property through getter and setter methods you can ensure that they only do things with the property that the object supports. If the property were only supposed to contain numbers between 1 and 10 for example you could write a setter that ensured it was never changed to anything outside that range. With direct access to the property it would not be possible to restrict that.
Getter and Setter methods have not historically been all that common in JavaScript since the language was not really built to support them. But in many other OOP languages like Java, C# and Swift getters and setters are extremely common, arguably more common that fully exposed properties.
Justin Duncan
8,465 PointsThank you for your response. My question was referencing a setter video for OOP in javascript. In this video, there was no mention of making the property inaccessible to the outside world(private). As such, I did not see the point in creating a setter with the same name as the property which would then force you to create yet another property in the form of (this._property). Then this required a new getter to return this new property completely abandoning the old property. I shall research more but to me, it just makes sense to change the name of the function(since this is the root of the problem having a function sharing the same namespace as a variable) so that you can just use dot notation to access it without creating another getter and another property.
I see your point but I do not believe that was the angle given. My understanding of the setter video in the javascript section was that you are required to use the same name as the property in which you wish to set, you then are required to create a new variable in this and create a new getter to access this new variable. Thus, leaving the original property essentially null. If it was about making the property private, then it should have been said and still, the methods should not be named the same as the property...that just makes no sense.
The lesson: https://teamtreehouse.com/library/setters
I am not a know it all, I am happy to be corrected I am just a bit confused on the reasoning here. I read the MSDN and it doesn't mention this style referenced in the video.
andren
28,558 PointsBut having a function sharing the name of the field is not the root of the problem, it is the intended effect. In order to behave like a property the getter/setter methods have to have the same name. And since the desired effect was for them to take the place of the owner field they have to be named that as well. In this video you can call the owner getter just by typing ernie.owner and can call the setter just by typing ernie.owner = "Ashely", if the getter and setter was not named owner then that would not work. The point of the get and set keywords is that you can have getters and setters that are transparent to outside code.
So to outside code it seems like there really is just a normal owner field on the object, and that's the desired effect. It should look like the object has a normal field that can be accessed directly, while in reality it is actually a property that is driven by getter and setter methods that can restrict how it is used. If there was also a real field named owner in the object then that would not work.
The way the getter and setter is used in this video creates something that in C# is referred to as a Property (I dont know if they have a special name within JavaScript).
As for the _property that is an example of a backing field. Since the getter and setter are methods they can't actually store any variables permanently (all of the variables they define are erased after they run) so in order to permanently set a value that can be gotten later you need to have a real field that backs the getter and setter up. In JavaScript there have not historically been any way of truly marking a field as private so instead a convention was formed. That convention was that if a field name started with an underscore then that was the developers way of telling other developers that the field is meant to be private, and that it should not be touched directly.
Justin Duncan
8,465 PointsThanks for the explanation! I rewatched the video as well and see that there was no property called owner in fact. So the getter/setter makes much more sense and I see the logic. My final question is, if there is a backing created can't that backing still be accessed/manipulated? Is there no true way to mark a property as private?
andren
28,558 PointsNo sadly there isn't really. JavaScript has historically lacked a lot of constructs that are considered common place in OOP languages. Classes and a lot of the behavior that is often bundled with them is part of the features that JavaScript has been lacking. It instead relied on the prototype concept, which offered some of the abilities you would normally associate with classes, but private fields was not one of them.
In ES6 JavaScript did finally add the concept of a class, but it is in many ways just a pretty wrapper around the existing prototype concept. And thus it is somewhat limited in what it can add and change about JavaScript's fundamental behavior.
There are some hackish and complicated solutions that will in effect result in fields that are not accessible outside the object, but there is no simple and proper way as you would find in most other languages. That is why the underscore naming convention came into existence in the first place. It doesn't prevent access to the field but it does make it obvious to most programmers that the field should not be touched, and that doing so is likely to be detrimental to the stability of the program.