ActionScript 3.0 Design Patterns

How to Decide on a Design Pattern

I don’t want to beat around the bush here, so I’ll just come right out and say it,

Choosing a design pattern can be tricky.

For most of you, this is nothing new. Even with the help of the Magic Table that shows what varies for each design pattern, I find that while the table is useful for eliminating certain patterns, it’s not as useful for pinning down the exact design pattern that should be used. So here is a case where you, as a reader, can help decide which pattern is best suited for creating the design pattern catalog that will be placed into an AIR application.

First, let’s look at the goal. Based on feedback from this blog, the conventions established by the Gang of Four as well as what I found useful, I came up with what each catalog page will display, as shown in Figure 1:

Figure 1: Mockup of Catalog Page

The idea is to have a single page with all of the data externally loaded. The class diagrams are to be a graphic image (including the text in the diagram), and everything else will be text. The text fields will either be for headers or body text, and the body text will have styles for normal text and code text (Arial for the former and Courier New for the latter). The color scheme, “Dusty Petrol” from Kuler, seemed to be a nice combination of colors without any jarring contrasts.

Key Operations

I like to start with a simple yet clear sketch of what has to be done for accomplish the task at hand. So, I began with the sketch in Figure 2.

Figure 2: Key Operations

As can be seen from Figure 2, the Client needs to make requests to get a graphic and text. The general approach is to load graphics using the Loader class and the text using the URLLoader class. The graphic will be returned as a Sprite object and the loaded text as a string.

A Strategy

As a simple and ever useful design pattern, the Strategy first came to mind. The algorithm could be changed, and new ones added on. In fact, I was thinking of reusing the design I had for the OOP Principles application. However, when I looked at it, I wasn’t so sure. I saw no return elements in the design, but I didn’t need any in creating the application for the principles; so I left it in contention. Figure 3, shows the sketch used in working through the process:

Figure 3: Strategy pattern

The graphics could be loaded simply by using the same structure used for loading SWF files in the Principles app. I’d just have to add a class with algorithms for loading text. Maybe I’d add an algorithm for creating different TextFormat instance for styling the text.

Factory Method

I must have been thinking about the Factory Method when I sketched out the general goal in Figure 2 because I did include returned values. Since I had already built an application using the Factory Method maybe I could reuse it. (The implementation of the pattern also included loading both text and graphics.) Figure 4 shows the sketch I came up with to think about using the Factory Method:

Figure 4: Factory Method pattern

After looking at the sketch and going over the Factory Method used previously that generated different products, each using both text and graphics, I realized that I’d either need 23 concrete product classes or I’d have to figure out a way to request 23 of something from the Client. Could the request be made through the creator? Would it be possible for the factory to generate all the strings required and place them in the appropriate text fields and position the graphic? My plan was to make 23 different folders with each item in the folder with the same name (e.g., design.png, name.txt, type.txt, etc.) and then all I’d need to do would be to reference the name of the design pattern make the call like so;

1
2

var dp:String=dpName;
var url:String=dp+ “/design.png”;

Whether that’s the best idea or not, I’m not sure, but it seems efficient and allows for easy change and loose coupling. Further, if it is a good idea, I still need to determine if the Factory Method is the best approach to the problem.

Chain of Responsibility

In looking at Figure 1, you can see all of the different header and body text loads required, and given the number of chores, I considered the Chain of Responsibility (CoR). I’d just set up concrete handlers for each of the different loads—one for graphics and several for text. Figure 5 shows what I had in mind:

Figure 5: Chain of Responsibility pattern

Initially, I was pretty enthusiastic about the idea, but the more I thought about it, the more I found it inappropriate. The intent of the CoR is to find the best way to handle a request and then have a concrete handler deal with it. I’d have to set up a loop to go through and use all of the concrete handlers for every request. I still like the flexibility of the CoR for this kind of application, and I can easily imagine adding more concrete handlers and changing existing ones.

What About Object Placement?

One of the challenges I seem to face again and again with design patterns using Flash/Flex is displaying objects on the stage. It’s not so much that figuring out the X and Y positions is difficult or the mechanics on plopping an object in a DisplayObject or DisplayObjectContainer, but rather how to take the generated data in the object and then pass it up the line to the point where it is displayed on the stage. On the one hand, I see that UI chores are usually the domain of the Client. The Client only requests the data (text or graphic) but is responsible for the housekeeping task of putting it where it belongs. On the other hand, why should the Client be saddled with a primary task in this kind of application? Further, is object display actually a UI element? Probably not. So, in planning object placement I need to think about passing the container objects (TextField and Sprite objects) from point of origin to the stage.

What About the UI?

As with other applications where the UI is simply a matter setting up some kind of selection object (like a List component), I’m perfectly happy with allowing the Client to instantiate and place it on the stage. However, there’s no reason not to re-use the Factory Method employed in making a selection UI for a video player to pump information into a DataProvider object. Further, the UI object is the Client’s requesting object; so there’s no need to fret about its instantiation. (That’s about the only easy thing in the whole project.)

Your Ideas, Please

Many readers of this blog have asked,

How do I decide which design pattern to use?

Unfortunately, it’s not a nice cut and dry answer. Rather, it’s a process where you look at the programming task and try on different design patterns and think about which one to use. I sketch out the diagrams as you’ve seen. It’s very much a matter of puttering around and trying to figure out what you need to accomplish both immediately and down the road as changes need to be introduced.

Some of you may be wondering why not use the same overall strategy used with the application that displays the different OOP principles? That application used several different SWF files where the text and graphics were combined in a single object. The main reason is that revising a SWF file every time you want to make a change can be awkward. I’d rather have something more granular where changes are simply a matter of modifying text in a text file than an entire SWF file. The graphic class diagrams could be done in Flash, but usually I just use a drawing program and load the drawing into Flash or Flex; so I’m really not saving a lot on the image production anyway if it is part of an SWF file along with the text.

So, I’d be very interested to hear what you have to say. I am open to just about any suggestion so that prior to building the mechanism for putting the ActionScript 3.0 design pattern catalog together I’ve got the best design pattern(s) at work.

Related posts:

1. The Developing an AIR ActionScript 3.0 Design Pattern Catalog and the AIR Magic Table