Comments on: To use getters/setters or not to user getters/setters, oh what a question…

By: Kyle

Kyle — Thu, 31 Jul 2008 16:17:40 +0000

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.

By: Stephen Buckley

Stephen Buckley — Thu, 31 Jul 2008 09:36:18 +0000

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

By: Limmy

Limmy — Thu, 01 May 2008 20:46:46 +0000

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.

By: Kyle

Kyle — Thu, 10 Apr 2008 20:39:26 +0000

This is great guys, I’m really diggin the back and forth and hearing everyones thoughts and ideas! Keep em coming!

By: walpolea

walpolea — Thu, 10 Apr 2008 17:23:09 +0000

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

By: enefekt

enefekt — Thu, 10 Apr 2008 00:47:51 +0000

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.

By: Kyle

Kyle — Wed, 09 Apr 2008 23:52:11 +0000

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…

By: Steve Bryant

Steve Bryant — Wed, 09 Apr 2008 18:17:02 +0000

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.