Flex and Java Differences: Getters & Setters

In Java it has become a standard practice to use a getter & setter notation to provide a consistent interface to an object’s properties. There is a reason why we don’t do the following in Java:

public String fullName;

The code above essentially creates an interface (or contract) between the class and the implementors of this class that does not allow us to change the underlying implementation of what gets returned when the fullName property is accessed on an instance of the class. So if someone has Java code that accesses the fullName property:

blah = obj.fullName;

Or sets the fullName property:

obj.fullName = "blah";

Then in Java there is no way to change the behavior of getting or setting the fullName property. If the author of the class wanted to change the underlying behavior of the getting or setting they would have to change how the implementors of the class interact with the class. That is obviously not ideal so in Java we typically hide properties with get and set functions. The Java language doesn’t yet have Java properties so we use methods to hide the implementation. So our Java class instead would be:

private String fullName;
public String getFullName() {
    return fullName;
public void setFullName(String fullName) {
    this.fullName = fullName;

This allows the class author to change the behavior of getting and setting the fullName property without changing the external interface.

In Flex it is not usually necessary to create the wrapper getter and setting functions on an object because ActionScript supports properties. This means that you can usually just create public properties like:

public var fullName:String;

If the internal implementation of getting or setting the fullName property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class:

private var _fullName:String;
public function get fullName():String {
    return _fullName;
public function set fullName(_fullName:String):void {
    this._fullName = _fullName;

To the class implementor the property fullName could still be get and set through the normal notations:

// getters
blah = obj.fullName;
blah = obj['fullName'];
// setters
obj.fullName = "blah";
obj['fullName'] = "blah";

Getting or setting the property would call the getter and setter functions instead of accessing the property directly. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes. This also allows a class to dispatch events when properties change (this is how Data Binding works internally in Flex).

I see a lot of Java developers who are wary of public properties on ActionScript classes. Don’t be! ActionScript supports real properties so you shouldn’t ever need property getters and setters unless you are doing something out of the ordinary. And you can switch to getters and setters without changing the interface to the object.

If you would like to learn more about the differences between ActionScript and Java check out my AS34J: ActionScript 3 for Java Developers eSeminar next week!

UPDATE: Watch the recording of my eSeminar presentation.

  • skin

    As usual.. explained beautifully!!

  • I agree with you, but when my VOs in As3 don’t implement functionallity or don’t have any “inteligence” (just has been a transport way) I use just public attributes even.

  • Unfortunately, I see a ton of people who have no idea why they’d want to use a protected/private variable. The key is to know what tools you have, and why you use them.

    Specifically: remember that public properties and functions are a CONTRACT. IF you change them, other people’s code might break. Use private by default, protected when you’re dealing with objects that might be extended via. inheritance, and public when you know your properties need to be accessed by other components.

  • nice post james! :)

    I’d love to see actionscript adopt a better approach than the set/get today? in that i love C# implimentation

    public Bank Owner { get; private set; }

    You can also add backing fields _owner , but at times you may not want them just yet but it does lend itself to allowing for that modification later on via the get; set; being padded out.

    Scott Barnes
    UX Consultant

  • mary

    how do we write test cases for setters and getters in flex?

  • mary

    Ya that’s correct james

    • I don’t think this is any different than testing any other property. Am I missing something?

  • Hi James a question when should I use a get or set in Flex? Action Script realemnte is necessary to use? or enough to have my public variables if you could not put a scenario where necessary the use of get and set in flex

    thanks very much

    • You only need getters and setters in ActionScript when you have something more than just getting / setting the property. Otherwise just use a public property.

      • Exactly, just follow the “book”. Implement setters for side effect behavior and pre/post conditions and getters to hide the structure behind or combined getters(which in principle is the same as the structure behind)

  • Scott

    That is the best explanation of this topic I have seen. Nice and simple. Thanks.

  • Dushyant Goswami

    Thank you very much for this article. After a lot of search I could finally find a place where “calling getter and setters from actionscript” was explained.

  • A “sealed class” is more efficient in Actionscript. What I mean by this is that the compiler and virtual machine require more overhead to make a variable publicly accessible than they need if that property is accessed through getters and setters. Also, using getters and setters in Actionscript provide the same upsides in flexibility that you mentioned here regarding code hiding. What you’re suggesting people generally do in Actionscript is kind of bad practice.

    • Why do you think it is a bad practice? And do you have any benchmarks that show that public getters/setters in front of private vars perform better than just straight public vars?

    • A “sealed” class is never good practice. Actually, is an annoying practice.

      Flex compiler figure out how to optimize code behind getters/setters. Is not just flex, is compiler techniques.

      You write code for others to read it, not for the VM to perform better. This is true in more than 99.9999999999% of the code I have written and read. And in more than 99.99999999999999999999% of the cases the customer is satisfied.

  • ActionScript 3.0 introduces the concept of a sealed class. A sealed class possesses only the fixed set of properties and methods that were defined at compile-time; additional properties and methods cannot be added. This makes stricter compile-time checking possible, resulting in more robust programs. It also improves memory usage by not requiring an internal hash table for each object instance. Dynamic classes are also possible using the dynamic keyword.
    Event handling is simplified in ActionScript 3.0 thanks to method closures, which provide built-in event delegation. In ActionScript 2.0, a closure would not remember what object instance it was extracted from, leading to unexpected behavior when the closure was invoked. The mx.utils.Delegate class was a popular workaround; to use it, you would write code as follows:
    myButton.addEventListener(“click”, Delegate.create(this, someMethod));
    Delegate.create(this, someMethod)

  • Akifgul38

    http://www.maryooyunlari.net I hope you visit my gaming site.

  • Gul38ster

    http://www.akiloyunlari.gen.tr You can play brain games!!! and too many playing game!!

  • Tejmo

    One issue with flex get/set methods: they take it on themselves to NOT execute if the incoming value is the SAME as the exiting underlying value. That is all the setters seem to have an implicit first line of:

    if ( input_to_set == output_from_get ) return;

    Is there any way around this? This has caused us much heartache in out project. We rarely have an issue here, but we sometimes do. Particularly we were interested to know if the setter was EXPLICITLY called (with the default value, e.g. null) by the instantiating code vs. simply never called at all.