What I meant in my post (from 2 years ago? yikes!) is that I don’t plan on using getters and setters unless they were needed for some reason (e.g., to make them read-only). I didn’t mean to imply that I wasn’t going to use properties at all!!

In a language like Java, you tend to use getters and setters defensively, just in case you may need them later. In a language like AS3, you don’t have to do that.

In the AS3 property implementation, it’s easy to create read-only (or write-only!) public properties. But only if you use the property syntax. If you just declare public variables, then there’s no way to mark them as read-only. So sometimes it makes sense to use the property syntax, even when you’re just writing dumb behavior-less getters, so that you can enforce asymmetric read/write access.

Of course, the AS3 property implementation is a thousand times better than Java, where public members are a very bad idea and you’re pretty much forced to write getters and setters. But the C# implementation is even better than AS3, because you can declare read-only member variables without having to use the property syntax. Very nice.

But even the C# implementation still has its flaws. For example, sometimes I’d like to declare a member variable as public-read-only, but private-read-write. The only way to accomplish that is to use the property get/set functions.

I’d love it if there was a way, purely using access modifiers on a member variable, to declare those kinds of asymmetric access modifiers.

In the mean time, though, I’ll keep writing those damn properties :)

Value Object Accessors

In J2EE, we would likely encapsulate our attributes as private attributes, with public getters and setters,
but in ActionScript, we recommend that you consider the following strategy that we adopt at
iteration::two.
In the simplest case in which we expect to be only getting or setting attributes, we choose to declare
the attributes as we’ve just shown, with public variables. Setting or getting attributes on a value
object is then as simple as this:
var account:AccountVO = new AccountVO();
account.accountNumber = “00310712”;
mx.core.Application.alert( “Account Number is “+account.accountNumber );
If the requirement on our value objects becomes more complex; perhaps we can do something a little
more clever in setting an attribute, for instance. Then we can encapsulate it by adding getter and
setter methods for the attribute.
5666 CH20 4/14/04 10:30 PM Page 23
24 Chapter 20 Flex Integration with J2EE
In ActionScript 2.0, we can use a feature known as implicit getters and setters and perform the following
refactoring:
public get accountNumber():String;
public set accountNumber( account:String )
{
this._accountNumber = “RN/”+account;
}
private var _accountNumber:String;
In this refactoring, we change the access of our accountNumber attribute from public to private, and
rename the attribute. (At iteration::two, our convention is to prefix with an underscore, although
many Macromedia classes use underscores in their implementations—and the compiler might warn
you if you happen to clash.) We then use the notation for an implicit getter and setter function, with
our function containing the same name we had for our public attribute. This then ensures that the
following code calls our setter—the implicit getter and setter ensure that a function call is treated as
if it were an attribute:
account.accountNumber = “00310712”;
In the preceding example, our motivation for the refactoring is shown as a requirement that
account numbers be prefixed with the fixed length string “RN/”.
This refactoring allows us to migrate from public attributes to public implicit getters and setter,
without affecting any client code (code that performs gets or sets).
We recommend this strategy over coding your own Java Bean style getters and setters.

Glad to see us agreeing on something !

It never occured to me that Ruby’s optional parentheses amount to the same kind of freedom. (I’ve never actually written a program in Ruby) Thanks for that insight.

I am doing a lot of Ruby now as well, and there it is the same (as you can leave off the ( ) in a method call. so one also have the benefit that later on one can change it without refactoring a lot of code.

But honestely, with eclipse and intelliJ, what is wrong with some refactoring. As long you know you are not working on a API or some infrastructural part, how big is the chance, really, that later on you decide to hide a public member and instead handle it with a getter… and what is so bad in refactoring then…

really, i tend to become more and more pragmatic about this kind of thing…

http://softwareaddiction.blogspot.com/2005/10/public-property-keep-out.html

The problem with Java is that you have to write over-engineered code