Well once upon a time, my answer would of definately been a resounding no....I, along with many other people from what I have read and heard never really saw the point to them. Why go through all the hassle of typing out all that extra code when you can just declare your variables as public so that they can be accessed outside the class?!
Well now I can fully see the usefulness of this little coding gem and how it fits nicely into proper OOP principles, I have done for a while and have been fully using them to boost the reusability of my frameworks, but only today really thought about how great they really are.
Public variables are great if you simply want your variables to be easy to access, but using a setter for something like this makes things a lot easier in the long run. Lets have a look at a real world example. Lets say you have created a custom class that creates a sprite with a text field. Now to change the text in this class from outside you would access the public String variable that difines the text, then you would have to access the actual text field of the class, which of course would have to be public for you to access it which of course opens the textfield up to be able to be edited from out the class....not good as you really want to have things like this closed, unless of course it really suits you to have the textfield as public, but any way it goes against the OOP principle of encapsulation. Also everytime you want to change the text in the textfield from outside the class you eventually have to enter more code as each time you access the string varaibale and also the textfield's text. So if we use a setter for this like so:
-
public function set text(txt:String):void
-
{
-
myTextField.text = txt;
-
}
Now one thing you will notice here is that through accessing this setter you automatically update the textfield so that the text changes, so that all you have to type when targeting the instance from outside the class is:
-
myCustomTextField.text = "blah blah blah";
One line to change the text, and also no need to access any string variables or even set them. Its is the same with getters also making assets and their properties and also private variables easy to access.
-
public function get text():String
-
{
-
return myTextField.text;
-
}
would simply be accessed with:
-
trace(myCustomTextField.text);
So you can see that getters and setters really are very useful and something that I seem to use pretty much in every class I seem to create these days, they not only keep your code cleaner and easier to read but make your classes seem to make more sense and function a lot better.
Happy coding
![[Valid RSS]](http://www.ultravisual.co.uk/blog/images/valid-rss.png "Validate my RSS feed")
Pingback: Tweets that mention Are there any benefits to getters and setters? | UltraVisual Blog -- Topsy.com
not to mention error checking and validating data that comes through. Ex. your textfield should only have email addresses in it. When you try to enter a improperly formated string an error can occur and be handles in any number of ways.
I’m not convinced by your example here. You’ve written a lot of code that you didn’t previously need, for little advantage. I think you might be in danger of breaking the single responsibility principle – although that depends on what the main purpose of your class is meant to be.
I think better uses are:
– when you need to define the variable in an interface
– when you want to make a variable read-only
– when you want to a value to be calculated each time it is requested
– when you want to notify other methods / classes when the value is changed.
HI Iain,
Thanks for your comment.
The example I have posted here is only one reason to use getters and setters. They have many other uses which is what I was trying to get across, my example may of not been a perfect one for portraying this, but it is one that I have found to be very useful in the past in executing other methods once a variable is set. You are very right in listing other reasons to use getters / setters and I totally agree. As for your comment on breaking the single responsibilty principle – in my example definately not, but as you say it would really depend on what else was going on in the class….but of course that is not discussed here…..
Agreed. I think what I really meant was that your example was possibly just too trivial to be worth implementing – but I understand you were just trying to give a simple example. I think real world uses are more illustrative. What I hate to see is a getter and setter for every variable for the sake of “correctness” with no real benefit.
Great article, thank you for putting all of this information together.
For arguments sake, what if you wanted to set the htmlText property for your myCustomTextField?
The example you’ve used can probably rely on the fact that the myCustomTextField is of type TextField, which obviously comes along with a whole swag of inherited public properties (of which htmlText and text are both included).
Perhaps a better example would have been to show some manipulation of the text within the text setter, or possibly even setting the htmlText field of the myCustomTextField object.
I agree with Iain on the many uses of getters/setters, frequently using them to create readonly properties and dispatch events notifying the rest of my application that a property has actually changed.
my 2 cents
This is one thing I love about AS3, the set and get keywords. Because without them, using setters and getters (as in Java) really is pain even for the caller. And on the other hand, Java has threads for example (really lacking those in AS3).