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…
I’ve been working on documentation, and I began thinking about the concepts of design patterns/OOP/principles and algorithms as the forest and trees, respectively. The documentation involves Server Side ActionScript (SSAS, which is ActionScript 1.0) and good old ActionScript 3.0 on the client side. (In this context, client refers to the client making requests from the server, and not Client as a class that makes requests from other classes in a design pattern.)
In previous posts I’ve admitted to being an algorithm junkie, and for the last several days that’s exactly the habit I’ve been feeding. Since I was documenting SSAS—ActionScript 1.0— which has no user classes or typed data, I can say with a straight face that I really didn’t have a lot of choice. However, the client side work with AS 3.0 could have been more OOP-like and maybe a little Strategy pattern could have been used just to get everyone off on the right foot.
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 Three-Question Survey
I’m working on a new post about ActionScript 3.0 Design Patterns at work. To help get an accurate measure of what folks are doing in the ActionScript work world, I put together a simple survey. The survey is made with radio buttons and check boxes; so it only takes a minute to fill out. Click below to take the World’s Easiest Survey:
ActionScript Design Patterns at Work Survey
We thank you in advance, and when we get the post up, you’ll see the results from the survey.
We finally finished judging the contestants and here are the results. Instead of having several categories for age, we decided to have only one because the ages did not have a great deal of range. Each of the winners happened to be from a different country, and so we can claim a true World Wide Contest. Congratulations to all! Download winning entries.
William Rafael de J. Ribeiro, BrazilOur grand prize winner created an interactive “funny face” using the basic Decorator and adding a second component class for a face and four decorator classes for angry, normal, and sad eyes plus a smile decorator. By moving the mouse around you can see the face change and eyes move.
Todd Coulson, U.S. Todd’s entry used a creative combination of elements to build a baseball diamond. The field was a simple rectangle, and it was decorated with an infield, the bases, a pitcher’s mound, boundary lines and players scrambling to the field. Todd is interested in adding to this foundation using other design patterns.
Timo Hannelin, Finland
Theoretical background for Timo comes from Katariina Nyberg’s article about phyllotaxis, fibonacci and the golden ratio. If we had a grand prize for the best algorithm, it would go to Timo. One algorithm makes an amazing amount of shapes—stars, triangles, squares, lines, shells, spirals…if you are lucky you will see almost all kinds of basic symbols. It also demonstrates that you can change a class in design pattern with a complex algorithm and it doesn’t faze it one bit.
Kevo X. Thomson, UK
Kevo had a very simple entry. By changing the x and y coordinates of the three concrete decorators, he was able to rearrange the images. Again, the change was made and there was absolutely no negative ripple effect. This is exactly what a good design pattern is supposed to do.
An Enigma Wrapped in a Clear Casing
The Decorator Design Pattern is an enigma wrapped in a perfectly clear casing. I can think of fewer design patterns that are clearer in terms of what they do or seem more practical. By using concrete decorations, you can change an object without touching its structure. You can pick and choose what features you want to add, and your central object (or Concrete Component) is untouched. You want to add another feature? ¡No problema! Just add another decoration. Likewise, if you want to remove an unwanted feature, just remove the decoration you no longer want. All of this changing is accomplished without touching the object all the while the object is effectively changed by the decorations. So updating is simply a matter of changing decorations and/or adding new components to be decorated. (Download all files for program here )
In our book, the most real world practical example was a car dealership where different models of hybrid cars (Components) were set up with different accessories (Decorators) to arrive at a final price. As different models of hybrids became available, they could be added to the components and as different accessories came and went, they could be added to the program without having to disrupt the structure of the program. The pricing of the car was based on both on the base price (Component) and the whistles and bells (Decorators) the buyer selected. Once set up, the site is easy to maintain, update and reuse in a different context.
In this post we want to provide a simple yet usable example that can be modified for your own needs. Many of the simple examples we’ve seen (or created ourselves) have made extensive use of string and numeric variables and/or trace output. Given the fact that practical applications make extensive use of such variables, there’s nothing wrong with that. However, we’ve found that the most difficult part of creating design patterns with ActionScript 3.0 is in making use of graphic materials and movie clips.
Read more…
The Contest
Okay, here’s a chance for Fame and Fortune. (We’ll supply the former; you supply the latter.) On Monday, April 27 you’ll find a new ActionScript 3.0 Easy and Practical Decorator Lunch Bucket Pattern on this blog. The contest will begin on Monday, April 27 and end Friday May, 22–2009. (That’s not a lot of time! But it should not take a lot of time to make the changes.) You can download the Decorator files here .
The contest is to see if you can change the Decorator design pattern in the new post, ActionScript 3.0 Easy and Practical Decorator Design Pattern.
Using the provided Component class (no changes allowed) and the provided Decorator class (no changes allowed) add new or changed Concrete Components and/or Concrete Decorators to make the most interesting program using the Decorator Design Pattern.
We have four age categories, and each category will have 1st, 2nd, and 3rd prizes. The Grand Prize will be given to the very best entry, regardless of age. Here are the categories:
- Under 18
- 18-25
- 26-40
- Over 40
All winners will be displayed on this blog along with their entries and photos. Read on to learn the rules.
Read more…
For those of you who have developed applications where a reference drills down through a series of movie clips, the Least Knowledge Principle may seem a bit harsh. It is very easy and even shows a semblance of foresight and organization to arrange operations in a movie clip set to have each movie clip do one thing in a complex object. To get something working, though, you do not want to rely on drill-down references that visit each of the many movie clips. Statements such as,
myMC_high.myMC_middle.myMC_lower.myMC_lowest.DoSomething()…
break the principle of Least Knowledge because it implies that each has some knowledge of the inner workings of the others. Likewise, anyone who has spent much time with JavaScript and the Document Object Model (DOM) knows that many of the objects have some hefty drill-downs in references. According to the Least Knowledge Principle, these are all ways to ask for trouble. Let’s see why.
Read more…
Bill Sanders
Recent Comments