ActionScript 3.0 Design Patterns
24 11 2007
I’ve been reading through O’Reilly’s “ActionScript 3.0 Design Patterns: Object Oriented Programming Techniques” by William Sanders and Chandima Cumaranatunge for the last few weeks and have to say its an incredibly useful resource.
The interesting thing is that this book approaches design patterns in the more traditional sense, not dumbing down on the object-oriented terminology. In that sense it is very approachable to those coming from a Java or C background and are looking for ActionScript 3.0 implementations of specific patterns.
On the other hand I can’t help but feel some patterns are shoehorned to fit in an ActionScript 3.0 context. True, ActionScript is a lot more like Java these days but there are still things that can’t directly be translated (or shouldn’t necessarily be).
One of my personal pet peeves is the way Singleton gets enforced, not only in this book but various other resources. The issue basically comes down to not being able to declare a constructor as private in ActionScript 3.0, thus no way of preventing the class to be instantiated using the new keyword. One common way to get around this is creating another class in the package declaration (there can only be one public class in your package declaration so it’ll be private) and using an instance of that “Singleton enforcer” class as an argument in your Singleton class constructor.
In my view this is an incredibly involved workaround which has its own problems (for example, you’re still able to pass null as an argument to the constructor and prevent if from throwing an error). It all comes down to personal preference but my vote goes to Grant Skinner’s approach — he proposed to use a simple Boolean property that defines whether or not the class can be instantiated, it defaults to false so if you try to instantiate the class using the new keyword it throws a runtime error. In the getInstance method, if the private instance needs to be created, the Boolean gets temporarily set to true and back to false after it was instantiated. Admittedly, the one downside with this method is that it throws a runtime rather than a compile time error but its as far as I want to go in creative workarounds to get a pattern to work.
ECMAScript Edition 4 is of course still a work in progress, but I for one can’t wait for it to support private and protected constructors and seeing ActionScript implement it.
The number of patterns they’ve been able to cover in this book is extremely impressive (Factory, Singleton, Decorator, Adapter, Composite, Command, Observer, Template, State, Strategy, MVC, Symmetric Proxy) and all things considered I think they found a balance in staying close to the original design while keeping it readable and straightforward to implement for the typical ActionScript 3.0 audience.
Design Patterns are a pretty dodgy subject to cover with zealots of the ‘committee for object-oriented purity‘ lurking around the corner ready to criticize your every line of code. Kudos to the authors for tackling the subject and making it such an approachable book!
I’d strongly recommend this book to anyone wanting to take a deeper look at the world of Design Patterns and object-oriented architecture.
Other books worth exploring are “Advanced ActionScript 3 with Design Patterns” by Joey Lott, the best selling “Head First Design Patterns” or even my own “Object-Oriented ActionScript 3.0” if you’re looking for a non-threatening introduction on the topic.
My rating: 
I couldn’t agree more on the singleton issue. You can’t do a “proper” singleton in AS3. I say just leave the constructor as public. You are going out of your way to try to replicate something that is not supported in the language. For what reason? Is all that extra run-time-error-throwing code actually going to do you any good? I say document it and if someone uses it wrong, that’s their problem.
When I need a Singleton in AS3 I usually implement all its methods and properties as static. That way it doesn’t matter if you use an instance (where creating an instance with the new keyword just acts as a getInstance) or target the methods through a class reference with the Class.method() approach.
It is kinda weird that AS2 supported private constructors and I was surprised to see that it wasn’t possible in AS3. I guess AS3 is more conform the ECMA spec.
You should consider recycling your post into a review on amazon.com
@Luke - ECMA is a cruel mistress, must be kinda fun for the engineers being able to blame all annoyances of the scripting language on it not being implemented by the standard yet
@Phillip - thanks for the suggestion, did exactly that
The Singleton is a touchy one. At the OOPSLA conference for the last two years, I’ve been informed by my betters that the Singleton is evil, no matter what. Also, with my focus more in State, Strategy and Flyweight dps, I’ve not been doing a lot with the Singleton. Even Erich Gamma said that he wished that they hadn’t included the Singleton in their book.
I worked with the Singleton a lot when we were preparing the book and I wish I had seen Grant Skinner’s solution earlier. However, since I didn’t, I’m glad that it’s been brought up here, and I’ll try it the next time I’m tempted to use the Singleton again.
Chandima and I are working through more design patterns at our blog at http://www.as3dp.com/. After a fitful start on the Flyweight (in 3 installments) I re-did the whole thing and presented it at OOPSLA using an air traffic control example, and it’s in better shape now. (I hope to get it up in the next couple of days.)
Thanks for the insights
Funny Peter, we had this same discussion last week with the dev’s at nascom. We were looking at Cairngorm (the dispatcher and so), and they (as Bill mentioned) thought Singletons were lame. “The pattern implemented for the sake of implementing a design pattern”. The consensus (as Luke already mentioned) is to use static instead.
I’m actually preparing a “design patterns” training for our new recruits, and I too have found Bills book a good resource
Hey Peter,
IS there any major differences between this and Advanced ActionScript 3 with Design Patterns?
Pete
Hi, I found the book quite boring and and useless. There’s a certain university textbook feeling to it: explanations and examples are too academic, not suitable for everyday agency/studio flash work. Compare the writing style and examples to Collin Moock’s Essential AS3 book…what a difference!
Useful book, thanks a lot
Hi, I found the book useless. I returned it to Borders. The least the authors could have done was, given that the subject matter was covered in GoF book, was give some serious AS 3 examples. I thought the names for the packages, interfaces and classes often muddied the subject matter. The must have explained that AS 3 has no abstract class at least ten times… filler.
The Essential AS 3.0 and AS 3.0 Cookbook are very good. The majority of people who find this book useful must be approaching these patterns for the first time.
Hi Peter,
It’s funny, we get these snipes who seem to follow us around whenever anyone says something good about our book, they say what Mike does–something vague and negative. Then they go on to praise Joey’s & Danny’s book. In effect, they are trying to make it an “Us vs. Them” contest.
This is annoying, but not for the reasons you might think. Chandima and I are truly interested design patterns and ActionScript 3.0 and not some kind of dumb contest. We’re glad more people are taking an interest in ActionScript and design patterns, and as you’ve seen at our blog on design patterns, we have lively discussions about them. (AS DP Blog). We’d love to see Mike and Czebe come out of the closet and join in that discussion rather than the sniping they engage in. It takes focus and energy away from the discussion of ActionScript 3.0 and design patterns.
Bill