To use getters/setters or not to user getters/setters, oh what a question…
I recently read a nice little article by Darron Schall (http://www.darronschall.com/weblog/archives/000149.cfm ) discussing the uselessness of getters and setters, and, after giving it some thought, I have to agree with him. The basic premise of a getter/setter is to you give access to a private property within your class, thus allowing a user of that class to alter the state of that property without knowing about or interfering with any other piece of the class. So Darron’s point is this: why not just use public properties? His point is a valid one. I think that the use of getters and setters is a bit of an old-school method that has become somewhat useless in its’ most basic form. This is not to say that getter/setters are completely useless however. They are still very useful if you want to perform some action on the data the user is setting/getting prior to updating the class or returning a value; however, for simply setting the input value to a private method of the class, there is really no point, and overall it just adds weight (in file size) to your code.
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
April 9th, 2008 at 10:17 am
I have to disagree here.
Take the example of a birth date. You may want to do some validation on that birth date. If it is a public property, you can’t.
This would mean that “fred” could be set as the birth date, which isn’t even the right type. It could also mean that the birth date could be a valid date, but in the future.
You might also have properties for which you don’t think you need any validation but for which you might later discover that you do have such a need.
Better to use getters and setters up front then later discover such a problem.
April 9th, 2008 at 3:52 pm
I agree with you on the fact that there are instance when you would want to use them (ex: validation, as I mentioned in my post); however, if you are doing nothing more than taking an argument and storing it in a property there is no difference between using a public property and using a private property with a getter/setter. I guess my main point is that if you have a class with a lot of properties that being set in this fashion, you can save a significant amount of file size by sticking with public properties. If you need validation later, then simply add the get/set methods then…
April 9th, 2008 at 4:47 pm
I liked Darron’s approach too when I read that post.
You can always seamlessly change them to setter/getters later if you need to.
The other thing is that if you’re writing an interface and not a class, then you can’t use public variables, but you can use getters and setters.
April 10th, 2008 at 9:23 am
Darron is right about AS3’s way of implementing getters and setters, it’s really just the long way around setting a property. However, take a look at C++ and you’ll see a hundred good uses for getter and setters. With function and operator overloading, templated classes, pointers and uber-strict data typing conventions, C++ is the sort of language that originated the idea of getters and setters.
AS3 implements getter/setters the way they do because if you are performing mutation or validation on setting/getting a value, the nomenclature for getting/setting a value doesn’t change.
this.myprop = “Blah”;
this code could be using a setter, or could be setting a public property, but the nice thing is, whoever is using my class doesn’t need to know there is a difference. I would hate it if half of a class’s properties were public and half had to be get/set using a function (as is done in C++).
this.myprop = “Blah;
this.setOtherProp(“Blah”); //annoying
April 10th, 2008 at 12:39 pm
This is great guys, I’m really diggin the back and forth and hearing everyones thoughts and ideas! Keep em coming!
May 1st, 2008 at 12:46 pm
I’m just looking forward to ActionScript 5.0. The whole getter/setter argument will be taken care of, trust me. I’m not allowed to tell you any more than that, cos it’s top secret.
July 31st, 2008 at 1:36 am
What about if you have a value object which store a set of properties for a view and needs to notify the view if a value changes?
The fact that you can dispatch an event if the data changes
July 31st, 2008 at 8:17 am
Generally you don’t want your value objects to be sending out any notifications. Value objects are supposed to be “dumb” and do nothing more than provide a predefined interface for storing data. What you’d want to do in this case is have the controller update the model (in this case your VO), then send an update notification to any interested parties (such as the view) to let them know the model has been updated, at that point the view would grab the updated data from the model (again, your VO) and make alterations as needed.
April 7th, 2009 at 11:31 am
I don’t know anything about ActionScript, but I found this post in a Google search when wondering why you’d want to use getters/setters in cases where literally all they do is get or set a variable. I found my answers in walpolea’s comment: for the possible complications he mentioned, and for consistency with variables that do require them. Thanks!
June 15th, 2009 at 11:54 am
“You can always seamlessly change them to setter/getters later if you need to.”
Maybe I’m confused, but I don’t think this would be a seamless change, as there is a syntactical difference between:
product.price;
and:
product.getPrice();
John
June 23rd, 2009 at 2:09 pm
I will never agree with that after what I went thru today. Setting 50 break points to track a data member.
If you ever have to debug an old application you will realize the importance of setter and getter methods.
Today I was debugging on Linux for our product(Primarily developed in Windows
but also supported on Linux). Its an old applications. I had to track a value of a member variable. I had to set 50 break points. That’s annoying and dumb.And when u don’t have a kool IDE you will feel the pain 
.
My take is all the class data member should have a setter and getter methods (private, protected). Its when the app becomes old and new people come in to maintain it they wont curse you as I did today.
October 1st, 2009 at 11:17 am
What if I want to lookup all the get* attributes of class while using an IDE, then I could simply say .get and see what all attributes are available. Yes, I do agree, that is there is a corresponding setter for a getter, then private-ness of the variable is useless, but get methods just present that convention to the programmer to lookup the public attributes of a class.
December 8th, 2009 at 2:24 am
Late reply, but that’s surely just bad design, how would adding getters and setters help the situation? You’d still be able to change the variable from anywhere.
And John, it’s because in flash you can use:
function get price(){}
so when you write product.price it automatically uses that function
July 23rd, 2010 at 8:40 am
Steve is right. With public properties you can only set values. With setters you can call others methods beside setting a value.