Archive for the 'Design Patterns' Category

Page 3 of 18

ActionScript 3.0 State Design Pattern: An Aid Game

Published on January 18, 2010 in State. by William B. Sanders 40 Comments
Take This One to Work

Take This One to Work

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.

<em><strong>Figure 2: </strong> State Pattern moves Helicopter Object</em>

Figure 1: State Pattern moves Helicopter Object

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

Continue reading ‘ActionScript 3.0 State Design Pattern: An Aid Game’

ActionScript 3.0 Design Patterns New Years Resolution

Published on January 2, 2010 in Design Patterns. by William B. Sanders 7 Comments

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.

ActionScript 3.0 Design Pattern Re-use and Modification

Published on December 23, 2009 in Design Patterns at Work and Factory Method. by William B. Sanders 0 Comments
Take This One to Work

Take This One to Work

Every Monday I have to separate out the paper, glass, aluminum, and plastic to recycle and take them up to the curb. This last Monday while engaged in this weekly ritual, I thought that recycling a design pattern might be an interesting exercise. Additionally, it’s the kind of design pattern advantage that can be used at work to save re-inventing the wheel when you have a similar development task. You may remember the Dragon Factory where we employed a Factory Method to set up an easy-to-use drag application. In the original Dragon Factory, both the Creator and Product participants had subclasses. However, with only a slight revision, it’s possible to create a little game for making different faces subclassing only the Product interface (abstract class). Figure 1 shows the File-Class Diagram:

<em><strong>Figure 1:</strong> Factory Method with Single Concrete Creator</em>

Figure 1: Factory Method with Single Concrete Creator

You can see the design similarities between this application (MrFace) and the Dragon application. The main difference is that this one has a single concrete factory (FaceCreator) for all of the concrete products. The factory churns out all of the Product children and puts them into an array. The Client requests the array from the Creator and pulls out the elements with a loop. As you can see, they’re all draggable elements. Try out the embedded SWF file below to see how it works:

MrFace

The same Product (from the Dragon application) is re-used so it is unnecessary to revise it. However, instead of a video and a dynamically generated graphic, all of the graphics were put into the Library as Sprite classes. (To make a Sprite class just change the Base class to flash.display.Sprite.)
Continue reading ‘ActionScript 3.0 Design Pattern Re-use and Modification’

ActionScript 3.0 Builder Design Pattern Part II: Multiple Builds

Published on December 1, 2009 in Builder. by William B. Sanders 1 Comment

As a concrete follow-up to Part I of this two-part post, I thought that once I decided on which graphics, text and video to use the development would go pretty quickly. It took a lot longer than I thought, but now that the concrete example is ready it’s pretty easy to see how to put a practical Builder together and re-use and extend it. Because this second part builds on the first part, if you’re only vaguely familiar with the Builder Design Pattern, you might want to review Part I.

What to Build?

In ActionScript 3.0 Builder Design Pattern Part I, we set up a vacation-building site using trace statements to display different characteristics. To make these characteristics come alive and work in some practical matter, the goal is to create a builder that does the following:

  • Load an external graphic
  • Play a video that can be displayed in any format used by Flash Media Server or Progressive Download
  • Display a different background for each vacation destination. The background is made of an external .swf file
  • Present text write-up using external text source

In looking at those four actions, you might be thinking, that’s not exactly rocket science. You’d be right. However, when you start adding more and more vacation destinations, keeping track of everything can dampen one’s resolution. With the Builder, though, I found it very easy to add, change, and delete. In fact, I encourage you to add your own favorite vacation place and add it using the builder described in this post.

The Design

In Part I, I talked about different variations in the Builder’s design. The one we’re using closely follows the first as far as the Product class is concerned. All of the concrete builder classes use the same Product class. The Product class assembles the different parts under construction. However, in order to keep the Product class manageable, I added several Helper classes to take care of the details for the different parts that need to be built for the final product. Figure 1 shows the file pattern for the design:

<em><strong>Figure 1: </strong> File Class Diagram of Builder Design Pattern</em>

Figure 1: File Class Diagram of Builder Design Pattern

As you can see, several classes use the Product class, and it uses all of the helper classes. Even the Client holds a reference to the Product class. As far as design is concerned, though, this one is identical to the one we used in Part I with the added helper classes.
Continue reading ‘ActionScript 3.0 Builder Design Pattern Part II: Multiple Builds’

PHP Chain of Responsibility Design Pattern from ActionScript 3.0

Published on November 15, 2009 in Chain of Responsibility and PHP. by William B. Sanders 6 Comments

smallchainARE Design Patterns portable from one language to another? Of course they are. I’ve read some accounts that claim otherwise, but I’ve not found any design pattern that could not be used in any computer language that I’ve tried. (Maybe I’m just conversant in languages where design patterns do work, but I don’t think so.) Anyway, Chandima and I have been discussing doing a set of PHP design patterns, and I wanted one for a contact form I had done using PHP.

For this blog, though, I thought I’d use a translation from one of the design patterns we have on this blog so that you can more easily see the similarities and differences between ActionScript 3.0 and PHP in implementing the same design pattern.

Chain of Responsibility

As you may recall from our Chain Of Responsibility (CoR) post, the design pattern is used when you want to have a system that takes care of requests when you have different outcomes. In our original example, we added a helper class called Request, but otherwise we stuck with the basics of the CoR structure. Figure 1 shows the class diagram of the CoR we used in our initial post.

<em><strong>Figure 1: </strong> Chain of Responsibility Class Diagram</em>

Figure 1: Chain of Responsibility Class Diagram

In this particular design pattern the Client class is a full-fledged participant in the pattern. Because Client classes are request objects themselves, it may seem odd to have a Request class. Just think of the Request class as a helper class that encapsulates requests for the Client.
Continue reading ‘PHP Chain of Responsibility Design Pattern from ActionScript 3.0′