ActionScript 3.0 Design Patterns

Last weekend I was somewhere south of Boston on an apple picking outting with the family, and I had to get back to Connecticut on business. From West Buckwheat (or wherever I was) I had to get to the Mass Pike and hot foot it to the Nutmeg State. Since the Mass Pike has only a few places where you can enter and exit, I had to find the wormhole that allowed me to get on the Pike from in the middle of nowhere. Recently I got a new car (2006 is new for me) and it came with a GPS system. Since I didn’t have a map I decided to trust the GPS system and set it for “Home.” Anyway, off I went through a maze of back roads that changed names every two blocks, and the trusty GPS took me right to the Pike. I thanked the GPS and told it I could take it from the Pike without further assistance, but it insisted on shepherding me home anyway. (Before I got my wife a GPS, she told me that she followed cars with Connecticut plates to find her way back from Boston–that’s why I got her a GPS!)

I digress. The point I was about to make is that one can use different navigation strategies. When I used to fly, we had VOR, Loran, ILS, radio beacon and visual landmarks to guide us around the sky. Back in the day, seafarers had sextants and compasses for celestrial navigation and dead reckoning. Suffice it to say that several strategies are available for navigation. That’s where I got the idea to create a Strategy design pattern using different navigation strategies as different algorithms. (Turn the page for the rest of the post.)

What’s New?

In our book (Chapter 11) and here on our blog, we’ve covered the Strategy pattern. So what’s new in this series? As explained in an earlier post, the plan is to get into a pattern from each of the main categories and saturate our heads in it. In that way, we’ll really understand it. Each of the three categories (Creational, Structural and Behavioral) will have a representative pattern to be saturated with little posts like this one. Better a series of little posts than one giant one. Why begin with a Behavioral pattern? That’s easy—next month I have to present a paper at OOPSLA (now SPLASH) on using the Strategy pattern, and I’m warming up here.

Let’s Get Saturated

Chandima and I usually kick things off with a class diagram. Here, I’m going to start with the participants in the pattern, and then the class diagram will make more sense. However, the very first thing is to provide GoF’s description of the Strategy pattern:

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

Okay, we know that the family of algorithms we’ll start with is a navigational one. So if client classes named Tom, Dick and Mary use a navigational algorithm, it can vary independently of which client is currently using it. They can use the same or different concrete algorithm (navigational tools), use more than one at the same time because the algorithms are loosely coupled to the clients as well as each other.

The Participants (AKA The Usual Suspects)

The Gang of Four are very specific about the roles of the participant classes and interfaces that make up a design pattern. An essential part of design patterns includes understanding what role each participant has, and then it’s easy to use the pattern by creating objects that fulfill the designated roles. The Strategy pattern has only three participants:

• Strategy (Interface/Abstract Class)
• ConcreteStrategy
• Context

What? No Client? After that rant about calling a client a Client, I have the cheek to start off with a design pattern where the Client is not a participant? (Just wait…)

Strategy

The strategy declares an interface common to all supported algorithms. Now remember, an interface can be either an interface or abstract class, and the GoF use the term interchangeably in this context. What this means is that you want to figure out some common properties and methods that you want to include in all of your algorithms. In this case, we’ll have to figure this out for a set of navigational strategies. Think family of algorithms.

ConcreteStrategy

The ConcreteStrategy simply implements the Strategy interface. The term implements refers to both implementing an interface and extending an abstract class in the GoF usage. Here is where we will put in the specifics of how our different navigational tools works.

Context

The Context has two jobs and possibly a third. First, it is configured with a ConcreteStrategy object. Second it maintains a reference to a Strategy object. It has the option to define an interface that lets Strategy access its data.

The Context participant is a busy little bugger, but just in case you think its like the Context in a State pattern, let me disabuse you of that notion. In the State pattern, the Context stores state, and it does no such thing in the Strategy pattern. Instead, the context acts as a go-between the client and the concrete strategies—the algorithms. The client typically creates a concrete strategy and passes it to the context and the context handles it from there.

So now, you see there is a role for the Client. What about Main? Well, you can take Main and xxxxx xx xx xxxx xxx. (Gentle reader, I had to edit Bill’s last comment. As soon as he returns from his court-mandated Anger Management class, he’ll continue the saturated series. Chandima.)

Related posts:

1. ActionScript 3.0 Strategy Design Pattern: Under No Conditionals
2. ActionScript 3.0 Easy and Practical Strategy Design Pattern