ActionScript 3.0 Design Patterns

Every now and then I find a quote about OOP or Design Patterns that I constantly reference. Instead of popping them into a text file (as I now do) I decided to put them in AIR apps. Then I could make them look like those goofy employee inspiration quotes some companies plaster around the cubicles (e.g., “Soar like an eagle!”). However, instead of inspiration, I chose reminders of what it means to write good OOP or DP. They’re not exactly the same as principles (which are in another AIR app) but just good guides. You can download them here in AIR files.

Here’s the first one, which you may recognize from previous posts:

If you have any similar quotes that you find instructive, send them along with their source, and we’ll put them up.

In the first part of this article, Friends with Benefits: Refactoring with Multiple Design Patterns—Part I you saw how a Factory Method design pattern was used to hold and deliver data to a DataProvider object. The Factory Method design pattern allowed for easy update by simply adding items to concrete products from a Product interface (DataSupply) or new concrete Product classes. New data can be added to the Concrete Products and the Client makes requests through the Creator interface. The request is filtered through the Concrete Creator to the Product interface to the concrete Product classes. Now, all we need to do is to refactor the player with a design pattern. However, before starting download the application (With 12 classes in the design patterns, a Client class plus three folders of videos, there’s a lot!) So first off, click here to Download All Files . You can see a working version of the player and multiple data sets here. These will help pull together all of the elements used in this project.

Here Comes the Big Bad State Machine

Before we get going on refactoring the video player application, we need to see where it will go in the context of both the State and the Factory Method design patterns. Figure 1 shows the relationship between the refactored player (State) and the factory that delivers the data (Factory Method).

Figure 1: Files for two design patterns in class diagram

The images are organized in an “open” folder, and the videos are placed in separate folders showing their relative position to the classes making up the two design patterns. The Client makes a request through the Factory Method to populate a List component with data from a DataProvider. Then, the request from the Client to the player can be made through the List component by clicking on the video selection. Figure 2 shows what the final product looks like so that you can more easily follow the refactoring:
Read more…

It’s about time for another Golden Lunch Bucket Contest, and once again you can reap fame and fortune! (And again, we’ll provide the former if you provide the latter. This time, though, we must insist that you provide better prizes for yourself if you’re one of the winners!)

If you’re feeling lucky, then enter the contest. Who knows? You might just win, and then you can go nuts! We know, you’ll have to put up with the paparazzi and the inevitable groupies, but that’s just the cost of fame. (Our former winners will give you advice on how to handle it all.) Just remember Dirty Harry’s advice:

You gotta ask yourself one question: Do I feel lucky? Well, do ya, punk?

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…

Gentle Reader, this post includes one completed application and one in the works. The AIR ActionScript 3.0 Design Pattern Catalog is meant to be a developer’s aid, and so your ideas of what to include in the catalog is important. We would really appreciate your comments on what you think would be useful in developing an information template to be used for all of the design patterns.

I recently returned from a trip to Prague in the Czech Republic, and I went to work creating a video player for my HD videos I made using a Flip Mino HD camcorder (http://www.sandlight.net/prague). Rather than pulling out and reusing my trusty State Design Pattern player (see Chapter 10), I decided to start from scratch and create a player not using a design pattern. Then I would take the completed video player and use it as an example to show how to refactor a program to a design pattern. (This will be in an upcoming post.) Since I’ve never had to refactor the original program (tweak, maybe but not refactor), and I hadn’t worked with a State pattern lately, I found myself digging up all of the materials on the State Design Pattern. What I wished I had was a handy desktop app that I could click that would show me the essentials of the different design patterns. It would be an abbreviated design pattern catalog that could be used like the little Design Pattern Principles and Lunch Bucket Rules AIR app. Then when I need a quick reference I could use the desktop app to look up the essentials of the pattern.
Read more…

A few weeks ago we had a survey to see the practices used by professional ActionScript 3.0 developers, and the results are quite interesting. Roughly, 31% of the respondents indicated that they used design patterns and OOP either as a strict policy in developing their products or from within a template. Another 51% indicated that given the time, they’d employ design patterns and all of the good practices, but because of time pressure, often they could not. The smallest category, representing 12% of the respondents, indicated that they didn’t pay attention either to design patterns or good OOP practices. In other words, 88% of the respondents indicated that they were aware of and attempted to use good development practices as a general policy except where it was impossible because of time and/or resource constraints.
Read more…