Let’s Not Perpetuate Misinformation
I’ve seen comments and blogs where the misinformed are leading the uninformed. The gist of the comments is of the nature that some ActionScript 3.0 design patterns are derived from Java or C# (or some other language.) Well, that’s like saying Java, C#, C++ and other languages got their patterns from SmallTalk. I’m sure that anyone who has begun with a design pattern for the first time needed to look at examples to get another view of the structure apart from a chart diagram. For those who used Gamma, et al for their starting point (which is just about everybody) then we’d have to claim that all design patterns are “borrowed” from SmallTalk. That’s just plain stupid in the context of what design patterns are all about. If no such examples, or good examples, can be found in ActionScript 3.0, then look in any other languages. The Gang of Four used SmallTalk for all of their examples. Some of these were quite helpful for finding the relationship between the classes/interfaces and can then be used to inform the developer what one might do with ActionScript 3.0. That’s it. Design Patterns are about relationships between classes and interfaces and it doesn’t matter what the language is they’re initially written in.
Built-In Design Patterns in ActionScript 3.0
One of the more inane comments I’ve seen is that design patterns should link into design patterns that are an inherent part of the ActionScript 3.0. (In the MVC example in our book, Chandima used that strategy.) Sheeeze! You can hook into a class/interface or an existing design pattern in any language or not. The built-in design patterns may be the best way to develop another design pattern or not. If it’s not; then build your own classes and interfaces along with the required methods and properties to get the job done.
Not at the Children’s Table
One of my in-laws is programmer in Boston using the traditional set of OOP languages and tools–C++, Java and the like. He’s politely dismissed ActionScript as a not quite language but had the good manners not to make an issue of it. In one of my last visits, he more or less said,
I see ActionScript is no longer at the children’s table. With ActionScirpt 3.0 and Flex, it’s all grown up now.
Naturally, I couldn’t agree more. I’ve always liked ActionScript, even in its infancy. However, behind the scenes at Macromedia, the engineers were agonizing over it. They wanted to dump all previous ActionScript code and re-program it from the metal up. Until ActionScript 3.0, all we got (according to the engineers at Macromedia) was one version of ActionScript stacked on an older version. Then with ActionScript 3.0 came the ECMAScript 262 standard version and a completely new language that acted like a true OOP language. Whohoo!
We’re No Happy Meal
From the comments of those who whine that design patterns have to meet some kind of ActionScript criteria to be good design patterns still think that ActionScript is the Happy Meal of computer languages. It’s not. So cut it out.
ActionScript offers a lot. The NetConnection and NetStream classes are my personal favorites, but the Loader class and other classes that are uniquely ActionScript, are strong features that make me want to stick with ActionScript. However, I must admit that certain kinds of other class-related access features would make ActionScript more available to design pattern implementation. I’ve learned to live with it, and with others will occasionally grumble to Adobe (or the ECMA). We do need a break from those who want to drag us back to the children’s table. It ain’t goin’ to happen.
One Last Rant: Bad Design Patterns
While I like enthusiasm in just about any form (except religious or political extremism), I’ve found an appalling number of listings on the Web that claim to be design patterns, but are not. Certainly, we encourage everyone and everybody to try their hand at design patterns based on the set provided by the GoF, but try and get it right. I’m still working on a passible–even a minimalist–mediator pattern, but it’s not easy. So before putting up a design pattern, take a close (make that very close) look at Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. The worse possible scenario is that ActionScript programmers begin emulating bad design patterns. If that happens, in no time we’ll be back at the children’s table.
The ActionScript 3.0: Not at the Children’s Table Anymore by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.
Related posts:
Bill Sanders
“The gist of the comments is of the nature that some ActionScript 3.0 design patterns are derived from Java or C#”
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.
Joel,
Beautifully put!
Bill
great post~!
@Joel – I believe you are speaking the same thing as Bill, only he was addressing the misunderstanding that Design Patterns have to do with a given language, as this is not the case. A Design Pattern is a pattern, and you can then use the pattern in a programming language. Just like a model drawing for clothes can be used with both leather and cotton.
Hi all,
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.
sorry for the offtopic.
i have purchased the book.I’m reading it but i can’t find the src of the examples..could y0ou if these files exists?
thanks!
@EzeQL
Source for all examples can be downloaded from http://examples.oreilly.com/9780596528461/