Source for all examples can be downloaded from http://examples.oreilly.com/9780596528461/

I like the model analogy.

By the way, there are a couple of clarifications I’d like to make. Chandima and I have never suggested that one not use built-in design patterns in developing their own applications. Rather, we believed that we needed to show every single element in each and every design pattern in our book. That is, we did not think that we would be as clear in explaining how ActionScript uses design patterns if we pointed to a pattern and simply said, “That’s a built in observer in ActionScript–go ahead and use it with these concrete subject classes.” We reasoned that most readers wanted to see what the observer actually looked like written in ActionScript. For those of you who have read GoF, you’re aware that on more than one occasion the SmallTalk examples used both built-in design patterns or just built-in functionality for which there is no equivalent in ActionScript 3.0. As a result, if you’re programming in any other language other than SmallTalk, you’re left with an informational black hole. By providing actual classes we built using ActionScript 3.0 for each and every design pattern and element in the pattern, the reader not only could understand how to create (and modify) the class elements in the pattern, he could also understand what he was invoking if he ever decided to use a built-in ActionScript design pattern.

So, while we intentionally did all the work to write our own classes for every design pattern in our book, we never suggested that using built-in design patterns or pattern elements (e.g., observer, state) was a bad thing. It just wasn’t as instructive to do so for the purposes of helping readers learn design patterns in ActionScript 3.0.

Beautifully put!

Bill

Why is this even bad? Of course these design patterns stem from the common patterns used in other OOP languages. It would be silly to reinvent the wheel now that actionscript has true OO features. I read Head First Design Patterns and AS3DP. The Head First book explains the patterns in Java, but they translate perfectly to AS3 in most cases. I just bought the GoF book this last week to go back to the source, but even just skimming I can see that while the sysntax is different the design patterns hold strong.

To me this is the fundamental reason to use design patterns in the first place. You can speak across syntactical lines with other developers and find common language based on design, rather than implementation of code.

I fully agree that AS3 is not at the children’s table. I can see this as true for AS2 or AS1, but AS3 is a very ‘real’ language, with lots to offer and a strong VM to run in.