ActionScript 3.0 Design Patterns

Monday we’ll start a new series for beginners in OOP and Design Patterns using ActionScript 3.0. The series will include examples from both Flex (Flash Builder) and Flash (Flash Professional.) The vote wasn’t even close, but because we believe that concurrent programming (parallel programming, multi-threaded programming) is so crucial to the future of both ActionScript 3.0 and programming in general, we’ll be issuing posts on those as well. In the same polling, there were requests for combo patterns, frameworks, and even one for MVC, but for the time being, we’ll be developing a series for beginners and I’d like to make a run at creating a virtual machine for doing concurrent programming in ActionScript.

However, since we agreed to let you decide, our next post will be to get those who are beginning, intermediate and advanced programmers through the worm hole and into the land of OOP and Design Patterns.

In the meantime ponder this: C’est magnifique, mais ce n’est pas la guerre. C’est de la folie. That’s how the new series begins.

A Three-Question Survey

I’m working on a new post about ActionScript 3.0 Design Patterns at work. To help get an accurate measure of what folks are doing in the ActionScript work world, I put together a simple survey. The survey is made with radio buttons and check boxes; so it only takes a minute to fill out. Click below to take the World’s Easiest Survey:

ActionScript Design Patterns at Work Survey

We thank you in advance, and when we get the post up, you’ll see the results from the survey.

We finally finished judging the contestants and here are the results. Instead of having several categories for age, we decided to have only one because the ages did not have a great deal of range. Each of the winners happened to be from a different country, and so we can claim a true World Wide Contest. Congratulations to all! Download winning entries.

William Rafael de J. Ribeiro, Brazil
Our grand prize winner created an interactive “funny face” using the basic Decorator and adding a second component class for a face and four decorator classes for angry, normal, and sad eyes plus a smile decorator. By moving the mouse around you can see the face change and eyes move.



Todd Coulson, U.S.
Todd’s entry used a creative combination of elements to build a baseball diamond. The field was a simple rectangle, and it was decorated with an infield, the bases, a pitcher’s mound, boundary lines and players scrambling to the field. Todd is interested in adding to this foundation using other design patterns.



Timo Hannelin, Finland
Theoretical background for Timo comes from Katariina Nyberg’s article about phyllotaxis, fibonacci and the golden ratio. If we had a grand prize for the best algorithm, it would go to Timo. One algorithm makes an amazing amount of shapes—stars, triangles, squares, lines, shells, spirals…if you are lucky you will see almost all kinds of basic symbols. It also demonstrates that you can change a class in design pattern with a complex algorithm and it doesn’t faze it one bit.

Kevo X. Thomson, UK
Kevo had a very simple entry. By changing the x and y coordinates of the three concrete decorators, he was able to rearrange the images. Again, the change was made and there was absolutely no negative ripple effect. This is exactly what a good design pattern is supposed to do.

The Contest

Okay, here’s a chance for Fame and Fortune. (We’ll supply the former; you supply the latter.) On Monday, April 27 you’ll find a new ActionScript 3.0 Easy and Practical Decorator Lunch Bucket Pattern on this blog. The contest will begin on Monday, April 27 and end Friday May, 22–2009. (That’s not a lot of time! But it should not take a lot of time to make the changes.) You can download the Decorator files here .

The contest is to see if you can change the Decorator design pattern in the new post, ActionScript 3.0 Easy and Practical Decorator Design Pattern.
Using the provided Component class (no changes allowed) and the provided Decorator class (no changes allowed) add new or changed Concrete Components and/or Concrete Decorators to make the most interesting program using the Decorator Design Pattern.

We have four age categories, and each category will have 1st, 2nd, and 3rd prizes. The Grand Prize will be given to the very best entry, regardless of age. Here are the categories:

• Under 18
• 18-25
• 26-40
• Over 40

All winners will be displayed on this blog along with their entries and photos. Read on to learn the rules.
Read more…

For those of you who have developed applications where a reference drills down through a series of movie clips, the Least Knowledge Principle may seem a bit harsh. It is very easy and even shows a semblance of foresight and organization to arrange operations in a movie clip set to have each movie clip do one thing in a complex object. To get something working, though, you do not want to rely on drill-down references that visit each of the many movie clips. Statements such as,

myMC_high.myMC_middle.myMC_lower.myMC_lowest.DoSomething()…

break the principle of Least Knowledge because it implies that each has some knowledge of the inner workings of the others. Likewise, anyone who has spent much time with JavaScript and the Document Object Model (DOM) knows that many of the objects have some hefty drill-downs in references. According to the Least Knowledge Principle, these are all ways to ask for trouble. Let’s see why.
Read more…

Gentle Readers: This short post is a request for feedback. The whole issue of appropriate level examples both in our books and this blog is an important one because it speaks to the utility of the writings and posts. So, your thoughts are not only welcomed; they’re essential.

I had a meeting with a computer scientist who was teaching a game class. In our short chat, he must have used the term real world a dozen times. Well, I’m all for the real world (in contrast to the unreal world of unicorns, fairy dust, and honest politicians). However, the real world for one is not the same as it is for another. Recently, I got a comment about a blog entry thanking us for a solution to a practical problem that one of our readers encountered in programming. The same post was criticized by another reader as not being real world. Therein lies the dilemma.

Abstract vs. Concrete

Chandima and I use a range of examples in our book. We start with an abstract minimalist example so that the reader can see the participants in a design pattern and then move on to something more concrete to illustrate a practical application. On this blog, most of the examples start with the more abstract elements and move into a fairly general (somewhat abstract) example that is more practical. The more abstract an example, the more general its applicability—not unlike an abstract class. However, the more concrete an example, the better the reader can use it to model a like problem in an eminently practical way. Each has its benefits. The abstract examples have generalizability and the concrete examples have needed detail.

Were I to do all of my examples using real world examples that I deal with, most would involve streaming video and Flash Media Server. My customers usually approach me for just that kind of problem. Obviously,using streaming video and FMS is real world, but its not very generalizable. Likewise, some readers complain that the abstract examples don’t help because they’re not practical.

We’d like your thoughts on this issue. Obviously, the most useful examples would be those that you deal with directly in your work, but like my practical work, it’s pretty narrow. Keeping these concerns in mind, tell us what’s most helpful to you.

This is one of the few design patterns that I worked up directly from the class diagram and from concepts in GoF. Normally, I like to look at some examples, done in Java or C#, but not this time. As you will see in Figure 1, the pattern appears to be fairly daunting, but I found it to be eminently practical, and it seemed to be a direct response to questions that I had about the Factory Method design pattern (See Chapter 2 for an in-depth explanation of the Factory Method.) You can download the entire example here before continuing if you wish.

 Let me start with the gist of the example from GoF and provide something more concrete that’s likely to be a typical kind of issue Flash and Flex developers deal with. Imagine a project where your designers have created general templates for a business site and another for a game site. Their templates include a SWF background and a set of buttons for a UI. The buttons are wholly programmed and require nothing in the Library, and so using them for either Flash or Flex is fairly simple.

 You want to keep your design loose, and so you decide that a factory will be helpful. However, clearly you will need a factory to create instances of both buttons and the background template. Further, you want your products to derive from an abstract class to give you as much flexibility as possible. In the example here, you will need an abstract product for buttons and another for backgrounds. You also want your factory abstract enough to make requests for sets of objects from the different products. For example, you want your factory to deliver both a set of buttons and a background that are matching pairs. You don’t want a set of buttons for a game site with a background for a business site, but rather you want the buttons to match your background—business buttons with a business background and game buttons with a game background. This is a job for the Abstract Factory.

 Figure 1 shows the class diagram. In looking at the “create” lines (dashed lines), think of them as working with matched sets. The Client requests a business set; and it gets both a business product for buttons and another product for background. So while the diagram may look busy, it really is doing something that makes sense on a basic level. That is, the design is geared to sets; of products with factories that create the requested sets rather than individual objects.

 

Figure 1: Abstract Factory Class Diagram
Note that Figure 1 shows that both concrete factories create instances from each of the child classes of the two abstract product classes. You can very quickly see the practicality of this when you substitute some concrete elements for the more general conceptual names.
Read more…

Gentle Reader: This is Part 4 of a four-part series of posts on introducing design patterns and OOP into the work place. Parts 1 through 3 will provide the context for this part. Also, taking a look at No Time for OOP and Design Patterns will give you the background on this series. As always, we invite your comments.

Note: Chandima wrote the chapter in our book on the Factory Method, and he gave me invaluable help on the main program in this post as well.

Recap

Up to this point we’ve examined a simple program that loads external text and graphics, a common ActionScript chore. In the most general terms, this is where we’ve been:

• Part I: Identifying the problem in a current solution. Why ActionScript on the Timeline can cause problems.
• Part II: Providing a simple OOP solution: Use of Inheritance
• Part III: Loosening Up a programs structure: Adding a design pattern element —a simple factory

To conclude the process, we now come to the last part—introducing an actual design pattern to the work place.

• Part IV: Establishing a Design Pattern Foundation.

Given the preceding steps, the context is now in place to add a full design pattern.

From Part to Whole

Part III introduced the Simple Factory method inserted into an existing OOP program. Now it’s time to step back and look at a design pattern en toto and instead of incrementally adding to the existing program, we will refactor the whole kit-n-kaboodle from the perspective of a design pattern.

To get started, if you’re not familiar with the Factory Method pattern, take a look at Chapter 2. In fact Chandima’s Sprite Factory example beginning on page 84 is one of the clearest and most appropriate examples that you can find of the Factory Method pattern in ActionScript 3.0. So before continuing, you might want to do a quick review of the Factory Method and take a look at Figure 1, the class diagram for the pattern. (We’ll wait for you…).

Figure 1: Factory Method Design Pattern

As you can see, the Factory Method (simple factory) is part of the Creator interface and the ConcreteCreator. The interface is an abstract class; so at least one of the methods needs to be abstract—impossible to directly instantiate but easily overridden in a child class.
Read more…

Gentle Reader:This is Part 3 of a four-part series of posts on introducing design patterns and OOP into the work place. Reading Parts 1 and 2 will provide the context for this part. Also, taking a look at No Time for OOP and Design Patterns will give you the background on this series. More so than most posts, we invite your comments.

Doing the Loosen Up

Few of you remember Archie Bell and the Drells, but their song, Tighten Up was a big hit back in the day. With design patterns, we want to do the opposite, Loosen Up. At this point, we’re going to do the Loosen Up. So put on your dancing shoes and look at the post No New is Good New. The purpose of the post is to get us to think about relationships between objects in a programming design. The dictum, program to an interface and not an implementation is invoked, and the post discusses different kinds of relationships found in design pattern diagrams. If you’re not sure about the issues involved, that post will help understand the next step in introducing design patterns to work.

At this stage in the series, we have arrived at one of the pillars of OOP, inheritance. Figure 1 shows a simple diagram of where we are now in refactoring the original application that used ActionScript on the Timeline.

Figure 1: Inheritance from a parent class

As you saw, inheritance allows developers to use the properties and methods of existing classes and in so doing saves time and adds consistency. However, a standard inheritance model also requires the client to instantiate all of the child classes that must be used. True, the instantiation can be through the parent class by initially typing the objects as the parent class rather than the child class as the following shows:

private var hci:Staff;
hci = new HCI();

The purpose of instantiating the parent is to make the link more general and flexible without breaking encapsulation. If the parent class changes, the objects typed to the parent have a better chance of working well without modification.

Read more…

Gentle Readers: Before reading this post, you’re advised to look at Take a Design Pattern to Work Part I: Identifying the Problem. It provides the necessary context for this post. Also, keep in mind that this series of posts is walking through a process and some of the steps may seem way too simple. We’re trying to imagine communicating with others who may not be as technically adept as you, and each step is simplified.

Getting Off the Timeline

As the readers of this blog are well aware, the Timeline in Flash is a valuable tool for animation. By using the Timeline in conjunction with symbols, IK and tweening, all kinds of wonderful creations are possible. However, the Timeline is not a good place for code, and again, this is nothing new to readers of this blog. So why bring it up?

If you peruse the ActionScript job openings at places like Dice.com and Monster.com, you’ll find openings that include the following requirements:

The successful candidate should have at least three years experience using ActionScript 2.0 with knowledge of ActionScript 3.0 a plus. He/she should also have the ability to maintain and update legacy Flash sites with ActionScript 1.0. A knowledge of OO programming and design patterns is strongly desirable.

Work that includes maintaining a site written in ActionScript 1.0 (and even ActionScript 2.0 in some cases) almost certainly means that some or all of the code is written on the Timeline and possibly even embedded in the individual symbols —buttons and movie clips. In other words, a good deal of the work is playing Where’s Waldo? with the ActionScript scattered all over the place. For me, working to maintain such a site is somewhere south of Dante’s 9th Circle of Hell. (You remember Dante’s Divine Comedy from that humanities class you had to take.)

In Part I of this post series, the code is embedded in an ActionScript layer on the Timeline. Maintaining the site is pretty simple both in making changes and adding new materials. The developer makes changes by changing the image file and the text contents in any single keyframe. Additions are made by adding keyframes in the Options layer, code in the ActionScript layer and buttons in the Buttons layer. That’s not a difficult plan. So why change?

With a relatively small staff in the company, there’s probably no reason to change it at all. However, as the staff grows or they want to add more to the site, especially in terms of additional graphics and animated materials, the size of the SWF file grows as well. Pretty soon, you’re making pre-loaders, and that’s a good sign that you’re in trouble.

In addition to the problems in generating a big fat SWF file, a single set of ActionScript statements can only grow into a larger and less manageable set of code. For a small application, it works fine, but as applications grow, unless some of the inherent problems are addressed, an error prone application begins to emerge. Change becomes more problematic and the program begins to lose functionality as well as flexibility.

Read more…