ActionScript 3.0 Design Patterns

Getting the States Straight

In a recent post to illustrate the use of composition and delegation, I created a simple game using a State design Pattern—the Aid Game. A lot of people had lots of questions and suggestions for making it better and being one who thrives on improvement and change, I promised to have a post where we’d review it as a State design pattern and not a quick and dirty example of composition.

In this post I’d like to go over some key elements of a State design and to see if we can improve on the original Aid Game by better design of state classes. Also, I’m going to leave the final repairs up to you—I’ll provide some guidelines for improved states, and you can implement them. Also, I’ll provide a little helper class that is an example of continuous movement based on one from our book that Chandima used to illustrate MVC. (I simplified it from the original; so if you look at the MVC chapter—Chapter 12—, you’ll only see pieces of it.)

Why a State Design and What are the States?

To get started, we have to ask the same key question that we should ask for every design we do. Namely,

What varies?

In moving the helicopter around in the Aid Game, the main thing that varies is the state of flight. (Each of the different directions and a stopped state represents a variation in state.) Ergo, I selected the State Design Pattern.

In our simple State design, I used five different states:

1. Stop
2. Move Right
3. Move Left
4. Move Up
5. Move Down

Next, I’ll add some rules that were not in the first version:

• Before reversing direction, you must first go to the Stop state.
• If a current state is called, it cannot invoke itself.
• Movement is continuous

Read more…

I’m tempted to say that aggregation is a stronger form of acquaintance, and that wouldn’t be far from wrong. In fact, in certain contexts it may be perfectly correct. Gamma, et al point out that the differences between the two is a matter of intent rather than explicit language mechanisms. That makes it a little tricky simply to show some code and pronounce, “See that’s what an aggregate looks like.” So bear with me as we look at aggregate relations.

Conjoined Participants

As can be seen in the red arrow symbols in the Participant Relations diagram at the top of this post, an aggregate relation is indicated by an arrow with a diamond at its base. The GoF illustrate the relationship as shown in Figure 1:

The Aggregator creates an aggregate instance of the Aggregatee. As noted, GoF point out that no single code set can demonstrate what an aggregate relationship looks like, but I think that we can get a start by looking at a fairly simple relationship in the State design I created so that we could discuss both aggregate relations and delegation. (The Strategy design also provides a good example of aggregation with delegation.)
Read more…

After creating the post on the acquaintance relationship between classes, I started thinking about the aggregate relationship and delegation. One of the best examples of delegation can be found in the State design patterns. All of the states are delegated to objects that handle each state. So I thought it’d be a good idea to create a little game that demonstrates both delegation and a state engine at work. Then, when I do the post on aggregation relations, I’ll have a simple reference point. This one is set up so that you can put it into your lunch bucket and take it to work. What’s more, it’s designed so that you can extend it into a more interesting game.

I decided that a good starting point would be to have a helicopter fly aid packages to different places on the screen. It would start at the airport and then fly the aid to different sprite objects representing groups of people in need. However, to get started, all I did was to set up five buttons to move the helicopter around the screen beginning at the airport. Figure 1 shows what the game looks like. (It is set up on an 800 by 600 display; so I had to cut off part of the right side to fit in this blog format.) The movement buttons are in the lower left portion of the screen.

Click on the Play button to get an idea of how it works:

Read more…

This post is the first in a series where I hope to discuss all of the key relationships between classes in Design Patterns. To help identify posts in this series I’ve created a general diagram with all of the different kinds of relationships between classes. I did not include the boxes for pseudo-code or divide the classes into areas for operations and properties. The purpose is to focus on the relationships in this series. You may have noticed that the chart is titled, Participant Relations, and by Participant, I’m referring to any class or interface in a design pattern using the Gang of Four’s terminology. In order to help you quickly see the current relationship topic, the Participant Relations diagram shows the currently discussed relations in red.

UML Controversy: Tempest in a Teapot

In this and subsequent posts, I’m sticking with the notations used by GoF. If you’re into UMLs, you’ll know that GoF actually use a few non-standard notations, but I think that by using the ones GoF use our discussion will be less confusing. If you’re interested in a more standardized UML notation take a look at Judith Bishop’s book, C# 3.0 Design Patterns (O’Reilly) on pp.4-5.

GoF discuss abstract classes and interfaces as interfaces. So, in an example where an abstract class is used, you’ll see an italicized class name. If an interface is used, you’ll see the same thing. In some respects this can be quite helpful in that when you see any italicized text in a class diagram you’ll think interface and know that you can develop your own design pattern using either an abstract class or interface.

The inheritance symbol, that we’ll be covering in detail in a later post, is used to denote both inheritance (extends) and implementation (implements). This is consistent with GoF’s interchangable use of abstract classes and interfaces and their notations. So bear with me on these idiosyncrasies and help focus on the relationships between participants.
Read more…

The other day I was worrying about a comment another programmer had made. After looking at some code, he twisted up his face and said,

“That’s not the way I’d do it.”

He went on to tell me how he’d do it. After thinking about it a couple of days I realized that the way he’d do it, while not wrong, wasn’t any better than what was originally there. In grousing about it, the chairman of the Computer Science Department remarked,

Yeah, that’s just like a programmer.

While that made me feel better, it was also aggravating. Out of sheer habit, what compels programmers to be so petty? I don’t mind a little one-upmanship, but some discussions need to be about finding a better solution and not forever trying to tell someone how smart you are. (By the way, this isn’t the first time I’ve mentioned this problem in a post, but I’d like this to be an invitational rant and get some reader comments.)

I’ve worked with people in a lot of different fields, and while some pettiness can be found in just about all professions, We’re Number One! when it comes to the That’s not the way I’d do it (TNTWIDI—pronounced tin-widi with a short “i”) syndrome.
Read more…

A while back I read an article by Miško Hevery that was part of a Guide for Writing Testable Code. Granted the stuff that Miško writes about is for the software engineers at Google, and my best guess is that it is primarily for Java programmers. (The examples are in Java and unfortunately [for us ActionScript 3.0 programmers] many of the solutions are through Java libraries.) Nevertheless, we can learn from the larger concepts and apply them to our projects.

Agile, Design Patterns and Unit Testing

If the senior programmers at Google (and I would imagine Adobe, Apple, Microsoft and elsewhere) have a mantra in programming, it’s probably something like this:

Keep it agile!

As most of you know (or suspect), Design Patterns are a type of Agile programming, and the development of both (DPs and Agile) in the 1990′s overlap in content and developers. They were all reading each other’s articles and contributing to one another through venues like OOPSLA and ACM (Association of Computing Machines). The agility movement was in part a reaction to heavy-handed, micro-managed systems of software development processes that were par for the course up to that time. This was not a rebellious overthrow so much as a realization that in order to get things done the processes had to change. In other words, Agile programming and Design Patterns were children of necessity as much as innovation.

The Agile Manifesto

In 2001, a number of developers put forth what they called the Agile Manifesto. It is a concise list of what they have come to value—here it is:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The forgers of the Manefesto go on to state that while there is value in the items on the right (normal), we value the items on the left (bold) more.

For those of you expecting something dramatic or revolutionary, you might be disappointed by this tepid manifesto. (These guys aren’t Marx & Engels even though they have PhotoShopped a picture to look like an impressionist painting of anarchists gathered in an ill-lighted London basement as they plan to overthrow the hoary capitalists). Nevertheless, you can see how such a value system is tied into a movement to get out from under the sludge dictated by a focus on protocols rather than results.
Read more…

First off, Happy New Year and Happy New Decade to one and all. By the end of 2010, I hope I’m a better programmer than in 2009.

In order to be a better programmer I need to have a good resolution. I’d like to do something better this year while not abandoning good habits I’ve picked up over the time I’ve been trying to be a better programmer. (That actually makes sense even though a bit convoluted.)

So, now I’ve got to come up with a resolution. The one I want will do the following:

• It has to be one I can keep. If I aim too high, I may miss the mark and feel I’ve failed to keep a resolution. Aiming too low is just a waste of time.
• It has to be forgiving. That means that if I don’t keep it 100% of the time, it’s ok. Improvement, not perfection, is the goal. Improving habits eventually become part of my programming DNA, and it’s a step in the ongoing trek to be a better programmer than I was at this time last year.

So my New Year’s resolution is:

Improve nailing down relationships between classes in design patterns.

For example, when I look at a design pattern with an aggregate relationship, I want to be able to immediately imagine what the code looks like for that kind of relationship and how it differs from an acquaintance or some other relationship. Eventually, this will enable me to look at a design pattern in a UML and see the code-class relationships and how it might or might not solve a programming problem.

I’ve probably got a dozen other resolutions for becoming a better programmer, but they’re sort of always there nagging and whittling, nudging me in the right direction. (My wife has thousands of resolutions for me; none having a thing to do with programming!)

Ok, that’s it for me. How about you? What’s your New Year’s programming resolution? Put ‘em in our Comments, and at the end of the year we’ll see how we’ve done.