ActionScript 3.0 Design Patterns

A Closer Look

I have no idea how things pop into my head or why. However, they do, and like unscratched itches, if I don’t attend to them they stay put. One such idea that cropped up was…

How do you drag a live video across the screen?

I have no idea why someone would want to do that either; so don’t ask. For 95% of you reading this, the answer is simple, but for the 5% of you in rehab this post may be of some use—at least until the pink elephants go away.

Because this is a Design Pattern blog, I should include some design pattern. I could slap a Singleton in front of it, but I pretty well shot my chances of doing that with my ongoing persecution of that miserable pattern. So I need to pose my question in a broader context,

What design pattern could be used to drag anything across the screen?

Well, put that way, we can make a more interesting project. This short post simply examines how to embed and drag a non-Sprite object in a Sprite object. In Part II, we’ll see how to create a design pattern that easily allows production of objects and placing them into a Sprite instance for dragging anything.

Hitch Your Wagon to a Sprite

Back in the days before ActionScript 3.0, about the only thing you could address on the stage was a MovieClip instance—or a derivative of a MovieClip. For some of us, the lesson was too well learned, and I often think, MovieClip instead of Sprite. Anyway, you can address a Sprite just as well and you don’t have the Timeline to go along for the ride. The trick back in the day was to dump anything you wanted to go along with the MovieClip into the movie clip. So if you had a graphic symbol, for instance, that you wanted to drag, you’d just put it into the MovieClip object and drag the movie clip. However, because the key methods of startDrag() and stopDrag() are part of the Sprite class, you can use the Sprite to do the same thing.

Read more…

Artists and Graphic Designers

For me, graphic designers and artists are angels. No matter how I try, I can only get so far in graphic design. Tools like clip art, templates, and Kuler help me achieve not awful , but that’s it. (I can even screw up clip art.) So, for anything serious, I’ve got to work with graphic artists. That’s no problem—I like working with angels.

Some graphic artist have made the transition to some version of ActionScript, but with ActionScript 3.0 most complained that they were getting left behind. Early Flash had few ActionScript options and a system for entering code that didn’t require any programming background at all. With ActionScript 2.0, things got better for developers, but designers started voicing concern over increased complexity. With ActionScript 3.0 and the loss of the ability to put code into buttons and MovieClip objects directly, some graphic artists became furious with Flash over what they saw as a betrayal. It was like a carload of kids on the way to do something fun ditched the artists and designers on the roadside.
Read more…

Gentle Reader: This is the second part of a two-part set of posts. For this one to be useful, please take a look at Part I. Also, I’m not an expert on military operations or organizations; so if there’s any error in a basic infantry platoon, feel free to correct me. I am aware, however, of the 7-1 ratio of Service to Combat units in the modern military, and that this is only a simple component of a far more sophisticated structure—that’s why I selected it!

In the first installment of the Wrong Way Warrior, we saw how an OOP developer put together a simple proof-of-concept using what he thought was a prudent approach to a battle simulation. He’d provide the Warrior with certain characteristics and then subclass those characteristics to concrete warriors that would share the capabilities of the parent class. In addition, the concrete warriors would be given a movie clip representation of the warrior.

After the first design was sent to the customer, the response was less than favorable. It was described as “a children’s game” at best. The military advisor described it as a caveman battle plan where all of the combatants are similarly armed with a club to attack adversaries. The problem was that it was bound to a fairly static design, and it would be impossible to be used for a simulation that had more complex behaviors. However, the other submissions were not much better, and so the customer provided a simple organization within the military to simulate—the basic infantry platoon. After all, they’re paying your company $1.5 million to develop the simulation. (This was news to the developer!) Figure 1 shows the organization in terms of a new set of movie clips:

Figure 1: Movie clip representation of platoon
Read more…

In preparing for this year’s OOPSLA conference where my session will focus on demonstrating good practices by showing examples of poor practices, I was reminded of the first chapter of the Freemans’ wonderful book, Head First Design Patterns (O’Reilly). To introduce the reader to design patterns in Java, the Freemans set up an example where a developer got in trouble because his program could not be expanded or changed without taking the whole thing apart and putting it back together again. In their wisdom, the Freemans wanted to kick things off with practical reasons for using design patterns—not just because doing so is the right thing to do.

In some recent discussions, I’ve heard references to OOP and design patterns as a religion or mockingly called “doing it right” as though design patterns are some kind of moral imperative by obsessive-compulsive developers rather than practical solutions to programming problems. Any kind of programming solution should be a solution that does a good job of solving a problem and nothing more. Discussions of OOP and design patterns as the right way to get things done has no resonance with me at all; so I’m the wrong person to suggest that faith in design patterns is sufficient reason to use them.
Read more…

The Case of the Crowded Client

After I made my video player that I planned to use to illustrate refactoring a non-design pattern program into a design pattern one, I noticed how crowded the Client class had become. Most of the crowding was caused by creating and populating UIs and event handling functions. One class that I use a lot to populate UI components is the DataProvider. As I went through and edited and organized my videos from a vacation to Prague, CZ, the DataProvider kept growing. Using MP4 files converted into F4V files, I used very similar formats for the data portion of all of the DataProvider instance. Why not put the DataProvider data into a separate class? Then, I could just call an instance of the class with the data and not have to clutter the Client class with messy DataProvider information.

Lazy Programming can be a Lot of Work

After moving the DataProvider data to another class, I realized that I had two other projects using the video player that accessed the same kind of data. So, while I was at it, I might as well add classes for these other projects. In fact, why not add a common interface as well? Then I could program all data requests to the interface instead of the implementation. Further, I could add some separation between the DataProvider items and the Client requests by adding a factory, and if I were going to do that, I might as well go ahead and create a Factory Method design pattern. Then, whenever I wanted to add a class with data for different projects I could do so without having to worry about messing up the rest of the program. Each project was handled using a Concrete Product class.

The Big Picture

To begin with a clear idea of what is going on in this refactoring exercise, you’ll need to get the big picture. Figure 1 provides an overview of how the video player is to be refactored using two design patterns:

The video player is essentially a state machine, and in Part II of this post, we’ll look at how we’ll refactor the hack-job player into a state player.
Read more…

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…

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.