Introduction

As the Flash platform has grown, the size and scope of Flashbased applications has increased. That growth has called for an everincreasing maturity in ActionScript developers. Flash applications have gained a new stature, and the increasing demand means that more developers must step up to the plate to hone their craft and take steps to evolve their understanding of and relationship with the code they write and the applications they build. Design patterns are a resource to help with just that.

ActionScript itself is really quite simple. It involves memorization of a basic syntax, a good API reference, and a decent IDE. What is challenging is not the ActionScript, but the architecture for an application. The real challenge is in deciding what classes to write and what the APIs for those classes should be. yet as you build more and more applications, you'll start to find that there are patterns that emerge time and time again. There are certain ways to accomplish tasks and solve common problems that occur frequently. These common solutions are the foundations of design patterns. Many of these design patterns exist already. If you don't bother to recognize them and apply them consciously, you will simply be writing applications the hard way. you might still end up with good results, but you'll be reinventing the wheel each time. Learning the design patterns helps you more quickly identify intelligent and effective ways to structure each new application.

The design patterns discussed in this book are but a subset of the many patterns that developers have created over the years. We've selected what we feel are some of the most useful and applicable patterns to ActionScript application development. These patternsand what we have to say about the patternsis not intended to be held as gospel. It is intended to serve as a guide and an inspiration for your own application development. The patterns we discuss are patterns that have been identified and recognized by programming experts over the years; by studying them, you can stand on the shoulders of giants. however, it's important to understand that these patterns are not rules. Just because an expert found something useful doesn't mean you are obligated to do so. Read everything with an open and alert, yet critical, mind.

Design patterns run gambit from those that require strict adherence to a specific interface to those that simply specify a generalized structure. Regardless of the ways in which specific design patterns play out or look, the intention is always the same: to solve a design problem. one example of a common design problem is that you need a way to create an object without specifying the concrete type at compile time. For example, a graphing application might need to be able to create and display a graph where the specific type (bar chart, line graph, and so on) is decided at runtime. If you specify a concrete type at compile time (for example, create a new BarChart object), then you are locked into a rigid structure, and you cannot easily change the type or add new types later. Because this is a common problem in many applications, developers have had to create solutions many times over the years. The solutions that have proven to be most useful, most elegant, most flexible, and simple to implement have emerged as design patterns that are learnable. one solution to the concrete type problem just described is a pattern we call the Factory Method pattern (discussed in Chapter 5.)

One of the fortunate sideeffects of working with design patterns is that they help you build a common vocabulary to effectively communicate with other developers. Imagine if you didn't have the word "car" in your vocabulary. Every time you wanted to talk about a car, you'd have to describe the object, perhaps saying "the object with wheels, an engine, and doors that typically seats 2 to 5 people and allows one person to conduct it by way of a steering mechanism." That would obviously make it rather difficult to have a quick and effective conversation about anything involving a car. having a word for something makes communication faster and more effective. For this reason, all the design patterns we talk about in this book have names. Rather than talking about "the pattern that allows you to capture and set state while maintaining good encapsulation," you can simply say "the Memento pattern."