ActionScript 3.0 Design Patterns

Changing How a Composite Object Gets Created

In both our book and on this blog, Chandima and I have tried to clarify and simplify ActionScript 3.0 Design Patterns and yet keep them accurate and, whenever possible, practical. After reviewing many, many Builder examples, I was surprised to find pieces missing in several instances, and while the examples may have combined elements (such as the Client and Director); others simply left out crucial components. (Who could forget bad, bad Leroy Brown who looked like a jigsaw puzzle with a couple of pieces gone?)

Given this state of affairs, it occurred to me that this pattern might be tricky; however, after working up an example, it turns out to be relatively simple and useful. Nevertheless, it’s not quite as simple as some, such as the Strategy or Factory Method, and so the discussion of the Builder is in two parts. This first part provides a clear overview so that you can easily see how the different components work together and starts a practical project., The second part (in a separate post) removes the abstract trace statements and displays actual content on the stage in a useful way. This will be to see if video, SWF, text, and images can be usefully integrated using the Builder.

Builder Overview

When you first look at the Builder class diagram shown in Figure 1, you might think it looks a lot like the Strategy pattern. Well, the class diagrams are similar, but the intent is very different. Also, you’ll find that the little Product class is hugely important.

Figure 1: Builder Class Diagram
Read more…

A little less than a year ago I published a post (really a rant) on this blog entitled ActionScript 3.0: Not At the Children’s Table Anymore. It was directed at those who looked down on us ActionScript 3.0 developers as serious OOP and Design Pattern programmers. It was also an invitation to take up the challenge to go beyond Timeline programming and use all of the new language tools and structures available in Flex Builder and Flash CS3 and CS4.

My enthusiasm was based on my great admiration for ActionScript developers and my firm belief that they were just as capable as any Java, C# or C++ programmer. That faith has never faltered based on what I have seen on this blog and in ActionScript 3.0 creations. In fact, if anything, it has been reinforced. ActionScript programmers take a back seat to no one.
Read more…

Probably the best place to start a discussion of loose coupling is with an analogy. Suppose you’re on a trip away from home and you want to buy a gift for your child. You don’t know the town you’re in that well, and so you ask the receptionist at your hotel where you can find a toy store. The receptionist suggests a nearby store, and you go there. It’s a big toy store, and so you locate a clerk to help you find the toy you want. After showing you several toys of the kind you’re looking for, you proceed to select one and purchase it. You ask the clerk if you can have the toy gift-wrapped, and she takes the toy to the back room and has it wrapped for you.

The process to locate, purchase and have a toy gift-wrapped involves interacting directly with two people—the hotel receptionist and toy store clerk. A third person may have gift-wrapped the toy, but you don’t know and don’t care. All you care about is getting the toy and having it gift-wrapped. The process is smooth because you are loosely coupled with the people with whom you interact.

You Can’t Handle the Truth

Let’s suppose that the receptionist at the hotel just found out that his girlfriend ran off with a traveling design pattern developer and is heart-broken. You don’t need or want to know that. All you want from the interaction with the receptionist is the location of the toy store. You want loose coupling with the receptionist. Knowing about the receptionist’s internal turmoil won’t get you what you need and may needlessly complicate things because you too are a traveling design pattern developer. Interaction between hotel receptionists and hotel guests is well defined and restricted.
Read more…

Sometimes a concept or principle is so simple that it can fly under the radar and no one understands it. For me, at least, this was the case for the OOP principle, encapsulate what varies. In the context of a program, encapsulation is the process of hiding the internal mechanisms and data structures behind an interface. To use the encapsulated operations (object, component), all the developer needs to know is what the component does. Then when the developer needs the component, all of the operations hidden in it are accessed by some kind of request—composition, inheritance or even simple instantiation.

So far so good. Encapsulation is pretty clear, and by the time you’ve decided to tackle design patterns, you should have some idea of encapsulation from OOP principles. The tricky part may be in understanding what is meant by separating elements that you expect to change and those that you expect to stay the same and encapsulate those that change. For this principle, we’re only interested in those elements that may change. Obviously, variables and data change values all the time, and so if we try to encapsulate everything that changes in a program we can quickly become entangled in a swirling flux of mutable elements.

What May Change?

In a recent Lunch Bucket pattern post that loaded SWF files, I noted that I was thinking about adding modules that would load XML files and text files. In other words, I was thinking about what may need to be changed in the program. So when discussing change the principle is not pointing to variables and data but adding components to the existing structure.

The added components are the change referenced in the principle.

All I really need to add (change in the program) is an algorithm to load XML files and another one to load text files. By choosing the Strategy pattern, I can easily add this new functionality by implementing the strategy interface with a new algorithm. The Strategy design pattern is specifically designed to handle change by adding algorithms; therefore, in that pattern algorithms vary and so they are encapsulated.
Read more…

Gentle Reader: This is one of those posts that begs for comments. It is partially tongue-in-cheek, so don’t get overly excited. However, since we do both produce products and provide services using OOP and design patterns, I thought it worth a cursory glance.

I’ve been refactoring a movie player/message board originally developed following the Where’s Waldo School of programming. It tucks ActionScript 2.0 in the Timeline in multiple frames, buttons, movie clips and God knows where else. The reason it’s an interesting project is because of excellent graphic design that I’m trying to maintain. Anyway, it’s almost done, and I was wondering whether refactoring using ActionScript 3.0 design patterns is a service or product.

When Services Became Products

Reading about the current economic meltdown in The Economist and watching the economic experts on TV, a couple of things became clear: (1) The major financial institutions have no idea what assets they have, and (2) a lot of the problems were caused because the assets were “re-packaged” into other “products.” Things became so convoluted that people like Bernard Madoff were able to buy and sell nothing to the tune of $40 billion and the SEC didn’t have a clue even when presented with evidence of a Ponzi scheme.

In order to avoid a similar meltdown in OOP programming, I thought it would be a good idea to ignite a discussion about the work we do and differentiate services from products. To begin, I thought I’d start with a list of products and services that seem to be pretty clear:

Read more…

This post is going to be short and sweet. I worked up a little application that you can see here. Also, I created an AIR version, and it now seems to work on Mac, Windows 7, Windows Vista and Windows XP. You’re welcome to download it here (AIR version) and put it someplace handy where you can quickly look up the main principles guiding OOP and design patterns.

Principles in Your Lunch Bucket

Here’s the whole idea of why I started this project in the first place. We need something that makes it easy to remember and use good practices at work. The posts reviewing OOP and DP principles on this blog is one resource, but something simpler (and sillier) would be helpful to have available when cranking out code under a deadline.

Yes, I practiced what is preached

When developing this little application, I started off the wrong way, and decided that no! Never again! I’d start off right, and it wasn’t any more difficult. I used a Strategy pattern, and later I’ll put the whole thing up here with an explanation of how this “work” project was done by following the dictums I was writing about.

So take a look and let me get your valuable (as always) feedback.

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…