AS3, DTOs, getters/ setters and good practice

! Warning: this post hasn't been updated in over three years and so may contain out of date information.

Yesterday I was adding some member variables (fields) to a simple AS3 Data Transfer Object (DTO). The existing fields were all marked private and there were public get/ set methods (properties) defined for them that did nothing but read and write to the fields. I really dislike using properties in this way. I can understand why one would do so in Java, as it lacks true properties and instead has getter and setter methods. Changing from a field to those methods changes a class’ interface, which necessitates rewriting any code that uses them. In AS3 though, this problem doesn’t occur. Changing:


has no effect upon the signature of something, so no code rework by classes using it is needed.

Despite all this, I struggle with the idea that using properties to wrap up the fields ought to be good practice, even though it appears pointless. I mentioned this on twitter and Neil Manuell lept to my rescue by agreeing it was pointless, so why was I doing it? Public fields were dutifully added to the class I was editing and I moved on.

There it might have have been the end of the matter were it not for that most strange of behaviours: twitter catch up. Many hours after the brief conversation between myself and Neil took place a really great trio of folk picked up on it. They are Robin Debreuil, Rasheed Abdul-Aziz and Lindsey “Stray” Fallow. Between them and Neil, they thoroughly explored the whole issue of fields and properties in AS3 and basically ripped my naive ideas to shreds.

The upshot of their discussion were these important points that I’d not really given proper thought to before:

  1. Interfaces cannot define fields, only properties.
  2. You cannot implement an interface’s read/ write property with a field in a concrete class.
  3. You cannot override a field with a property in a child class.

The following example hopefully illustrates these points:

So with that in mind, I now feel happier with the idea that avoiding public fields wherever possible really is good practice when writing AS3 code. Even if you are creating a simple DTO be aware of the limitations of public fields as explained above. Creating properties for those fields might involve extra time and boilerplate code, but it can reap rewards later if the code is modified.

So it’s now time for me to go back and change those public fields to protected and add wrapper properties around them…

6 thoughts on “AS3, DTOs, getters/ setters and good practice

  1. It’s a tricky one. I suspect the “best” approach is some degree of flexibility in what you choose.

    Any DTO’s I use are generally very simple and have little or no logic in them. Coupled with the fact I generally never have to implement a DTO that combines others (except by composition), there’s no real reason for me to have an interface for that DTO rather than a solid class. So, for most of my code, I’d use public variables for DTO’s.

    On the other hand, for any class that allows access to it’s data, it’s generally safer to wrap protected/private vars with public accessors.

    Even there I have a few exceptions though. If the class is holding data that needs fast access, I’ll use public vars (accessors are at least an order of magnitude slower for accessing data). And if I know that the class isn’t really interface material, I’ll be tempted to use public vars. That’s a risky one though because I always end up using things in unexpected ways 😉

  2. @Mnem I was about to add optimisation reasons too.

    also using Robotlegs I will inject public vars in mediators and commands as they are inwardfacing…

  3. An interesting point that this raises is the Immutability of your DTOs. Personally, I am strong believer that Immutability (making an object unmodifiable after it is created) reduces the complexity of a system by eliminating state changes – this makes you code easier to read (You’re guaranteed that a given object is still in the state it was constructed in) and easier to test (you no longer have to test how modifying the state of an object during operation effects Clients which make use of it).

    IMHO, you don’t need all those setters, just getters; if your constructor ends up having too many arguments then consider making use of a Fluent Constructor via a Builder:

  4. I say: where are you using the code? If it’s for your own use or part of an internal project that all the people working on understand fully, then who cares? Public vars can very easily be refactored into getter/setters if you need to implement an interface or override. If it’s a group project where the contributors might not have a full grasp on the code base (they might only ever use a small part of it) or a project to be released to the general public, then sure, make it more verbose and flexible.

    Personally, I don’t know why properties aren’t included in interface definitions.

  5. If a particular class consists of just properties, why would you need an interface? If the getters/setters have no side effects, the implementation and the interface are the same, no?

Comments are closed.