ActionScript 3.0 Design Patterns

After my introduction to design patterns a few years back, I kept trying to find the sine qua non of design patterns. The more I looked, the less impressed I’ve become with the reasons for using design patterns and the more impressed I’ve been with design patterns themselves. That last sentence may sound like an oxymoron (and maybe it is), but it means that the more design patterns that I’ve used, the more sense they make. Still, such an endorsement hardly sounds like an articulate rendering of the “why” in design pattern usage. So I’d like to use this blog to articulate the reasons for using design patterns and invite others to contribute their comments on the topic in the hopes of clarifying what these reasons are.

First of all, the work by Gamma, Helm, Johnson and Vlissides was not meant for people like us. By people like us I mean those of us who came into their own as developers writing ActionScript and other languages that seemed to have been gathered under the umbrella of ECMAScript. ActionScript programmers are a relatively new breed considering that it was added to Flash slowly from a few statements in the early versions to start and stop the playhead. Now, with the first real implementation of ECMAScript in ActionScript 3.0, it has come into its own. The universe of people like us has broadened to include programmers with computer science degrees and serious purposes beyond the hobbyist. My own case was grounded in Fortran II and meandered through BASIC, assembly language, FORTH, and then on to Internet languages like JavaScript, PHP, and C#. Without a doubt, the brightest bunch of programmers I ever hung out with were FORTH programmers. At the time I was going to weekly meetings at General Dynamics in San Diego with professional programmers who did things like write a program in FORTH on the fly and have it communicate with the Space Shuttle. Members of that group were so smart that they could imagine a functioning program and go off and write it in FORTH, and it would run circles around any other attempt to do the same things in languages like C++. In fact they scoffed at C++ and other languages that were getting puffed up about being object oriented. To the engineers using FORTH, working with objects came naturally, and considering that FORTH was (and still is) an assembly language, that’s no small feat.

Given that background, I’m not the kind of person who is impressed by the latest thing, especially after working with world-class programmers whose programs stood up where C++ failed. However, given the direction of the ECMAScript standards and the importance of OOP for those standards, I wanted to do it right. After working with OOP more or less for a number of years, I was never convinced that it offered a great deal. In part, this is because most of the programs I wrote were relatively short, and they stood the test of time both in functionality and my ability to upgrade and change them. Also, I was of the belief that a good algorithm was worth all of the overblown code offered by OOP. So, OOP started off as a nice-to-know instead of a must-have.

Common Collaboration Among Objects

After seeing that people like Aral Balkan, Peter Hall, Colin Moock and aYo Binitie were doing some very interesting things with ActionScript and design patterns, I started working to understand how design patterns could be of value. Reading and re-reading Gamma, Helm, Johnson, and Vlissides (better known as the Gang of Four or simply, GoF) and the Freemans’ Head First Design Patterns (O’Reilly), until the ink was coming off the pages, it dawned on me that design patterns are really a roadmap to good OOP. In the Foreword to Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley) by GoF, Grady Booch notes that he judges OOP programs by the attention developers pay to the common collaboration among objects. When I thought about that comment for a moment, it was an epiphany that clarified the real purpose of both OOP and design patterns. Objects in OOP are just that – objects. The real value in OOP is how objects are related and how they work together smoothly. For me, Booch’s comment is the sine qua non of design patterns. So, with that as a base, I’d like to look at some other reasons to seriously consider design patterns.

Streamline Resource Usage

Recently, aYo Binite said that he believed that design patterns’ key contribution to programming is to streamline resource usage. That is a beautiful way of putting it. The resources are the different objects in a program. Paying attention to how they interact and work together to streamline current and future resources is an essential part of any program.

Speed Up Programs

Nobody likes to wait for a program to perform a task. Heavy-handed coding and slopping on bit-mapped graphics with a trowel often slow down Web-based efforts. As programs increase in size, the possibility of slowing down because of increased number of objects and complex relationships increases as well. Some design patterns, such as the Flyweight, are designed to organize objects in such a way to speed up the resources used for object reference and use. The result is that the user doesn’t spend that much time waiting for the program to get its act together and fully execute.

Less Likely to Crash

As programs increase in size and complexity, different elements are likely to bang heads and freeze up the operation. Design patterns are roadmaps to avoid conflict and assist each object to perform optimally by itself and in conjunction with other objects. Once debugged, I cannot remember every having any of my programs freeze up and crash.

Reusable Code

Reusable code may sound like nothing more than a copy-and-paste operation. However, as the subtitle to the Gang of Four’s tome, it needs to be considered in the context in which it is used. If you’ve ever tried to take code from a big program and copy and paste it to create a new program, you may have found that you run into one kind of problem or another. Things don’t quite fit, and you find that you’re better off chucking the whole thing and starting over. With a good design pattern, you will find it easy to maintain a structure and make a few changes to have an entire new application. Also, the same structure can be used in different ways to create different applications simply by instantiating the classes in different configurations.

No related posts.