ActionScript 3.0 Design Patterns

In the little AIR menu with the 10 principles one of the clearest is the Open/Closed Principle. At one time this principle suggested that all updates be created using an implementation or extension of virtually any class. That could get tricky, especially if someone understood that to mean implementing an update or extending a subclass. However, later, the extension came to mean the extension of an abstract base class. In other words the interface is extended but never modified. Given these caveats, we can understand the basic principle as it is now understood:

Classes should be open for extension but closed for modification.

Easy to Take to Work

(Note: In talking about a program and changes, we’re not including the Client class. It just makes requests, and you can add requests and change them all you want in the Client.)

The idea that when you want to change a program, the only way you are able to make changes is by extension may seem a little restrictive. However, what the principle is really doing is providing a way to make changes without having to rewrite the whole program. The dictum, New behaviors are only available through extension should not be phrased in a way to make it sound like it’s tying your hands. Rather, it should say something like,

Hey! The Open/Closed principle makes it easy to add new behaviors without having to mess up your whole program.

Read more…

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…

Recently on this blog I created a little application to be used for a quick lookup of the different principles used in both OOP and Design Patterns—The Lunch Bucket Rules. The app uses a Strategy design pattern that is both simple and practical. The pattern is designed to load external SWF and graphic files (.gif, .png, and .jpg) and nothing more. You can pop it on a USB drive and put it on your keychain, and you’ll have a simple design pattern that you can take to work and use whenever you want. If you need a simple design pattern starting point, this should do the trick. (You can download the whole thing, including source code and swf files if you like.)

Swiss Army Knife of Design Patterns: The Strategy Pattern

The Strategy pattern defines a family of algorithms, encapsulates each and makes them interchangeable. Figure 1 shows the basic look of the Strategy pattern:

Figure 1: Strategy pattern Class Diagram

An interface (Strategy) describes the abstract signatures for the algorithm to be used with a family of algorithms. The key here is understanding that when developing a Strategy pattern that you need to think through the implications of the abstract methods you’ve got as part of a cluster of related algorithms. Given that this example only has a single Concrete Strategy class, you can assume that you have an opportunity to add more concrete strategies, and at the end of the post I’ll suggest a few.
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…