ActionScript 3.0 Design Patterns

Extrinsic States
In the first part of the Flyweight Saga, I had the idea that a Flyweight design pattern would be a good idea because it would be useful for cranking out buttons on the stage. However, the comments by the readers have led me to reconsider that idea; so it’s back to the drawing board. This revised Flyweight is going to focus on adding an extrinsic state parameter. Also, I got rid of all but one of the concrete Flyweights and am now down to the FlyButton class only in order to focus on extrinsic states.

Keep in mind that this process is a matter of working out the specific sense of a Flyweight pattern more than it is to show the optimum example. In going over some Flyweight materials from MIT, they suggested having a grasp on other, simpler patterns like the Observer and even MVC before tackling the Flyweight. This was both comforting and worrisome!

Extrinsic State Parameter

To get back on track (somewhat), this new Flyweight includes a parameter for extrinsic states in the Flyweight interface. Because the state is extrinsic, it changes with the Flyweights context. As discussed briefly in Part I of this saga, the extrinsic state changes with the context while the intrinsic state does not. Thus, the extrinsic state is not shareable (a shared object) and the intrinsic is. A concrete class can be sharable or not, but it cannot be if it does not store the intrinsic state. However, both sharable and non-sharable concrete Flyweights can exist. The following summary might be helpful.
Extrinsic state

Cannot be shared
Depends on flyweight’s context
Client is responsible for supplying extrinsic state when needed

Intrinsic state

Can be shared
Stored (inherent) in the flyweight
Does not depend flyweight’s context

Read more…

All 532 pages Now Available
ActionScript 3.0 Design Patterns has been published and is now available anywhere you buy books. Amazon.com has indicated 328 pages, but the actual page count is 532 pages. So just figure you get an extra 200 pp free!

Free Sample Chapter
You can get a free sample chapter at: Decorator Pattern from O’Reilly.

Table of Contents
Check out the Table of Contents TOC to see the topics and design patterns covered. Examples can be written in Flex or Flash CS3.

Two books I have include Design Patterns in their tittles, but neither actually deals with the kind of Design Patterns that GoF deals with. One is Jennifer Tidwell’s Designing Interfaces: Patterns for Effective Interaction Design (O’Reilly). In this book, different UI design patterns are discussed. The general patterns Tidwell examines are those found in everything from human behavior to UI interfaces. They include names like Safe Exploration (a human behavior pattern), One-window Drilldown, (information architecture) and Hub and Spoke (navigation). From the get-go, I don’t think that anyone ran out and bought Jennifer’s book thinking that they were going to be learning about the kinds of Design Patterns found in the Gamma, Helm, Johnson, and Vlissides book.
Read more…

Michael Baczynski has developed a package of common data structures useful for game development. However, their utility far exceeds game development and will come in very handy for application development based on design patterns. I came across this resource while searching for an AS3 hash table implementation. In addition to hash tables, the package contains ready to use structures for multi-dimensional arrays, queues, stacks, trees, heaps, graphs and vectors. The API docs are available as well.

I ran across the Flyweight design pattern when looking for a pattern that could be used to speed up placing objects on the stage in a Flash application using ActionScript 3.0. The Flyweight name implies a somewhat insignificant design pattern, but after working with it for a few months I found it to be both powerful and informative. It is powerful in that it is one pattern that actually speeds up operations, and it’s informative in that key OOP concepts are used and illuminated in it. It’s also one that has taken a while to really put together right—a process I’m still working on. Because this is a work in progress, I’d like to invite any and all developers with an interest in ActionScript 3.0 and design patterns to comment.
Read more…

This is part 1 of a two part composite pattern example implemented in ActionScript 3. The composite pattern comes in handy to develop complex structures consisting of simpler parts or components. The components can be primitive objects or they can be containers that hold other components. An example will help explain this better. Think of a house as a composite object. A house consists of a roof and several rooms (living spaces). Each room can contain windows, chairs etc. The house and rooms are composite objects as they contain other components. However, we can consider the roof, windows, beds and chairs as primitive objects. The composite pattern makes building, accessing, and manipulating composite structures simple by enabling the client to treat both composite objects (that contain other objects) and components (primitive objects) the same way through a common interface.

The following example develops a book in Flash. A book is a composite object as it contains several pages. This is by no means a functional book, but a conceptual example to illustrate the utility of the composite pattern. One of the big advantages of design patterns is extensibility: allowing the application to expand and add new features without breaking existing functionality. We will extend this example in part 2 by adding composite pages that can contain text and images.
Read more…

Doug Crockford, Chief JavaScript Architect at Yahoo, did an excellent four part video series (each about 30 minutes long). Doug has a nice presentation style and covers most of the foundational elements of the language. There is a lot to learn here for ActionScript 3.0 programmers because of the common ECMA Script foundation in both languages.
Read more…

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.

Read more…

In AS2, declaring a constructor as private in a class prevented it from being instantiated. Unlike AS2, constructor methods cannot be declared as private in ActionScript 3.0. This killed the simple runtime check for abstract class instantation. Sho Kuwamoto, Senior Director of Engineering at Adobe describes the thought process behind the omission of private constructors in AS3.

A more creative approach to implementing abstract classes is necessary in AS3. The issue of preventing instantiation of abstract classes in AS3 has been looked into very throughly by several developers such as Tink and Mims Wright. The solution is quite simple, but how do we make sure that abstract methods have been implemented in subclasses as well? This post describes one solution (Mims has another) to this issue using the concept of type introspection in ActionScript 3.0.
Read more…