Flexible Design Pattern Re-used with Flash Builder Development

A couple of days ago, we had an example for beginners creating a mobile application using Flash Professional. We used an Android example because everyone can get the tools they need for emulating an Android. (By the way, partnering up with Google-Android and Flash was a brilliant move by Android. Being an “Apple Guy,” I thought I’d be doing nothing but apps for my iPhone and iPads; however, Android made it a lot easier to develop apps for Android using some kind of ActionScript 3.0 development tool, and Blackberry’s not far behind. So I am very happy to know that iOS is now available, but they’ll just have to wait their turn for a beginner’s post.) As promised, I wanted to create a beginner’s example using Flash Builder. This example uses the same Strategy Pattern as the Flash mobile tutorial. However, as you will see, there are some key differences when dealing with Flash Pro and Flash Builder. Also, I hope you see that a very different logo (FB instead of Sandlight) and text. All that was changed for this difference was swapping the image used for the logo and the text in the external text file. Also, I had to change some settings in the BringText class, but that too was easy and didn’t upset the program. Why? Because it was a design pattern!

Stepping Through Flash Builder Mobile

This is going to be the same walk-through with Flash Builder as with Flash Pro but with a few differences. The Flash Builder work flow is slightly different, but you will find more similarities than differences. Before we get going download Flash Builder 4.5.1. (You can use the 30-day free trial version.) You can probably work with FB 4 with all of the updates, including the Android SDK, but everything in this example was done with FB 4.5.1. (If you are a student or faculty, you can get a free educational version of FB if you contact Adobe with your student or faculty ID. Faculty can get it free for their classrooms and labs as well.) Install to the defaults. Go to Adobe Labs download and install both Adobe AIR 3 (beta) and Adobe Flash Player 11 (beta) and let’s get started:

First, open Flash Builder and select File > New > ActionScript Mobile Project. (Note: You will find both a Flex Mobile Project and an ActionScript Mobile Project; be sure to select ActionScript Mobile Project.) In the Project name window, name the project FBmoStrat as shown in Figure 1 :

Figure 1: New ActionScript Mobile Project window

I used the default location and the default SDK, which was Flex 4.5.1. Click Next.

Second, when The Create an ActionScript Mobile AIR Project window appears with the Mobile Settings tab selected, you will see that all Target platforms (Apple iOS, BlackBerry Tablet OS and Google Android) are checked as shown in Figure 2.

Figure 2:Initial Create Window

Third, uncheck both the Apple iOS and BlackBerry Tablet OS. When you do that, the Permissions for Android appear as shown in Figure 3:

Figure 3: Android Permissions

Be sure that the Platform is Google Android and that the only permission checked is INTERNET. The default is to Automatically reorient the screen in the Application settings. Leave that default checked and click the Next button.

Fourth, in the Build Paths step, you will see a set of default selections you can leave alone except for the Main application file that you want to change from FBmoStrat.as to Client.as. Figure 4 shows the step correctly configured:

Figure 4: Build Paths step

If your Build Paths steps looks like Figure 4, click Finish. You should see the following script automatically generated:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

package
{
	import flash.display.Sprite;
	import flash.display.StageAlign;
	import flash.display.StageScaleMode;
 
	public class Client extends Sprite
	{
		public function Client()
		{
			super();
 
			// support autoOrients
			stage.align = StageAlign.TOP_LEFT;
			stage.scaleMode = StageScaleMode.NO_SCALE;
		}
	}
}

The Stage Align and StageScaleMode built-in ActionScript 3.0 classes will help align the application when it is turned in different directions. The super() method invokes the parent class Sprite. You will be leaving the constructor function as is but add more materials for the Client class. Before doing that, go ahead and test the problem and download all of the files with the buttons below:

You still will need to test the file from Flash Builder and contend with one last set of settings. So gather up all of the files and read on before testing.

Testing from Flash Builder

Once you all of the classes in the project are saved in the Flash Builder src folder, along with the graphic file and text file, click the Run button to test the application. The first time you do this, you will see the Run Configurations window shown in Figure 5.

Figure 5: Run Configurations window

In the Launch method area, select the On desktop radio button, and select Mororola Droid 2 and click the Apply button. Finally, click the Run button.

The Strategy Design Pattern in a Mobile Context

If you read the post on creating this app using Flash Pro, there’s not much new here. This post is only meant to show how to add a design pattern into a mobile application using Flash Builder. If you use apps on mobile devices, you must be aware of the updating that your app goes through. Using the Strategy pattern, adding more concrete strategies is easy, and changing the graphic and text contents is equally easy. In other words, this is a very flexible tool to both create and update mobile applications just as it is with traditional applications. The following classes are little changed from the previous post using Flash Pro, but they are included for review and the small differences that could impact your understanding.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142

//Client
package
{
	import flash.display.Sprite;
	import flash.display.StageAlign;
	import flash.display.StageScaleMode;
 
	public class Client extends Sprite
	{
		protected var context:Context=new Context(new BringGraphic());
		protected var contextTxt:Context=new Context(new BringText());
		protected var mobileSprite:Sprite=new Sprite();
		protected var textSprite:Sprite=new Sprite();
 
		public function Client()
		{
			super();
 
			// support autoOrients
			stage.align = StageAlign.TOP_LEFT;
			stage.scaleMode = StageScaleMode.NO_SCALE;
			setLogo();
			setText();
		}
		protected function setLogo():void
		{
			mobileSprite.addChild(context.bringLoad("mobilelogo.png"));
			mobileSprite.x = 5,mobileSprite.y = 10;
			addChild(mobileSprite);
		}
 
		protected function setText():void
		{
			textSprite.addChild(contextTxt.bringLoad("mobile.txt"));
			textSprite.x = 5,textSprite.y = 150;
			addChild(textSprite);
		}
	}
}
 
//Context
package
{
	import flash.display.Sprite;
 
	public class Context extends Sprite
	{
		private var bring:IStrategy;
		private var bringObj:Sprite=new Sprite();
 
		public function Context(bring:IStrategy)
		{
			this.bring = bring;
		}
 
		public function bringLoad(url:String):Sprite
		{
			bringObj.addChild(bring.contentLoader(url));
			return bringObj;
		}
	}
}
 
//IStrategy interface
package
{
	import flash.display.Sprite;
	public interface IStrategy
	{
		function contentLoader(url:String):Sprite;
	}
}
 
//Bring Graphic--loads graphics and SWF files
package
{
	import flash.net.URLRequest;
	import flash.display.Loader;
	import flash.display.Sprite;
 
	class BringGraphic implements IStrategy
	{
		private var urlReq:URLRequest;
		private var loader:Loader;
		private var objNow:Sprite=new Sprite();
 
		public function contentLoader(url:String):Sprite
		{
			urlReq = new URLRequest(url);
			loader=new Loader();
			loader.load(urlReq);
			objNow.addChild(loader);
			return objNow;
		}
	}
}
 
//BringText -- loads external text and xml files and formats text
package
{
	import flash.display.Sprite;
	import flash.text.TextField;
	import flash.text.TextFormat;
	import flash.net.URLLoader;
	import flash.net.URLRequest;
	import flash.events.Event;
 
	public class BringText implements IStrategy
	{
		private var textContainer:Sprite=new Sprite();
		private var urlNow:URLRequest;
		private var txtLoader:URLLoader=new URLLoader();
		private var txtFld:TextField=new TextField();
		private var txtFormat:TextFormat=new TextFormat();
		private var uLoader:URLLoader;
 
		public function contentLoader(url:String):Sprite
		{
			urlNow=new URLRequest(url);
			txtLoader.addEventListener(Event.COMPLETE, addTxtFld);
			txtLoader.load(urlNow);
			return textContainer;
		}
 
		private function addTxtFld(e:Event):void
		{
			uLoader=URLLoader(e.target);
			txtFormat=new  TextFormat();
			txtFormat.font="Verdana";
			txtFormat.size=24;
			txtFormat.color=0x000000;
			txtFld.defaultTextFormat=txtFormat;
			txtFld.multiline=true;
			txtFld.width=300;
			txtFld.height=300;
			txtFld.wordWrap=true;
			txtFld.x=10,txtFld.y=50;
			txtFld.text=uLoader.data;
			textContainer.addChild(txtFld);
		}
	}
}

If someone would like to add their own logo and text about their company, services or products using this application, we’d like to show them off. It’d be a good use of the design pattern, and you’d get some worldwide notoriety for your company!

ActionScript 3.0 Design Patterns in Mobile Apps

The very first mobile app I want to build is one that I can give away to promote my company or my clients’ companies. Yes, I’d like to make lots of money with a mobile action game like Angry Birds, but in order to get started, I want something that I can easily update and change. It seems like every time I check my phone apps, I’ve got updates. What is one of the main features of Design Patterns? Easy updates! So, if you want to create mobile applications in ActionScirpt 3.0 that are easy to update, you’ll find design patterns your BFF!

This first one is built with Flash CS5.5. If you do not have Flash CS5.5; download the 30-day trial version. If you’re using Flash Builder, use FB 4.5.1. or download the trial version. (I hope to have a FB tutorial using this same example later in the week. In the meantime, take a look at Christian Peters’ mobile example for building an app using design patterns with Flash Builder.)

This first example uses a Strategy pattern with algorithms for loading external images (or .SWF files) and text. That is exactly what I need for a mobile app promoting my company. With the image loading capability, I can load my logo and any images that show off products and services. The concrete text strategy loads up data from external text files. So this ought to be the easiest app to update imaginable!

Easy Android

I was going to start off with an iOS example, but I realized that most of you probably didn’t want to shell out the $99 developer fee required by Apple for iOS development. So, instead I decided to use an Android example that you could test using an Android emulator. To get started, go ahead and download the source code and see what the app displays:

All of the Downloads have been moved to the University of Hartford’s Multimedia Web Design and Development Program page. The last entry under “ActionScript 3.0/ Flash” should have what you want. (I’m still working on it to include a short description of each entry–it’s in the database; just not on the screen).

When you run it, you will quickly see that a logo and block of text pops up. That’s it. Swap out your own logo and texts, and you’re in business. You can change any of the parameters in the BringText concrete strategy class to alter the text appearance, it’s placement and other features to suite your own tastes or business brand.

Starting from Scratch

Since this is a first time experience for beginners and mobile (which may include experienced ActionScript 3.0 programmers), we’ll step through the set-up beginning with the FLA file. So read on through the following steps:

First, download and install the Android SDK. If your system is not automatically selected, choose the correct OS. Install the SDK.

Second, install the Adobe AIR 3 beta and Adobe Flash Player 11 beta, both at Adobe Labs.

Third, download and install Flash CS5.5 trial if you don’t have it. (If you have Flash CS5 and have installed all of the updates, you ought to be ok.)

Fourth, in your root directory, create a folder named “Developer.” For example, on a Mac, you’d open up your Macintosh HD and add the Developer folder.( A hammer icon may automatically appear on the folder.)

Fifth, open Flash CS5.5 and select AIR for Android. Configure the screen for 320 x 470. (If you have an Android phone with a different screen size, configure it for your phone size.) Create a folder named MobileApp inside of the Developer folder, and save the file as AndroidStrategy.fla.

Sixth, with the stage selected, open the Properties panel. In the text window labeled “Class” enter the Class name “Client.”

Seventh, in the Properties panel in the Publish grouping, you should see AIR for Android next to “Player.” You will see a wrench icon to the right. Click the icon to open the AIR for Android Settings window. Figure 1 shows what you should see. If anything looks different, check to make sure you followed the previous steps.

Figure 1:General AIR for Android Settings

Eighth, in the AIR for Android window, click the Deployment tab (near the top of the window next to the General tab.) Figure 2 shows the Deployment selections. You will need to create a Certificate and Password. Click the Create button to create a certificate. You can use any names you want; something simple works fine. You can use the same certificate for other projects. I had placed the Android SDK in the Development folder and once I created the certificate, the full URL is:

/Developer/android-sdk-mac_x86/platform-tools/adb.p12.

If you do not see a “platform-tools” folder in your SDK folder, you’ll need to update your Android SDK by downloading the most recent release. (The earlier ones had the needed files in a different folder.)

Figure 2: Deployment Tab in AIR for Android Settings Window

Be sure to remember your password, and it helps to click the Remember password for this session so you don’t have to keep re-entering it. Set the Android deployment to Emulator release and don’t select any of the After publishing checkboxes. When you’re all finished click OK. You’re all set for a mobile app using design patterns!

Adding the Design Pattern

This final section uses a simple Strategy design pattern. (If you’re not familiar with the Strategy pattern, we have a saturated series on it as well as a simple introduction.) As noted at the outset, this implementation of the Strategy pattern pulls in graphics and text through Client requests. However, because of the pattern design, there’s minimal object binding, and any updates or changes will not unravel the whole program. Also, because it’s simple, it’s a good pattern to use to understand the basics of the Strategy pattern.

The Client

Without a UI, the pattern is quite easy. The Client simply requests what it wants using literal names for graphic images and the text in an external text file. The following shows the Client code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

package
{
	import flash.display.Sprite;
	public class Client extends Sprite
	{
		protected var context:Context=new Context(new BringGraphic());
		protected var contextTxt:Context=new Context(new BringText());
		protected var mobileSprite:Sprite=new Sprite();
		protected var textSprite:Sprite=new Sprite();
 
		public function Client()
		{
			setLogo();
			setText();
		}
 
		protected function setLogo():void
		{
			mobileSprite.addChild(context.bringLoad("mobilelogo.png"));
			mobileSprite.x = 5,mobileSprite.y = 10;
			addChild(mobileSprite);
		}
 
		protected function setText():void
		{
			textSprite.addChild(contextTxt.bringLoad("mobile.txt"));
			textSprite.x = 5,textSprite.y = 150;
			addChild(textSprite);
		}
	}
}

The protected accessors have been employed so that when the app is developed in Flash Builder in the Flex element, it’ll feel right at home. However, in this Client, private access would have worked fine. This particular implementation of the Strategy returns Sprite objects containing both Text and Graphics, including other Sprite objects. As a result, even the text is added to the stage inside a Sprite. Notice that all requests go through the Context class.

The Context Class and Strategy Interface

Even though the pattern diagrams for the State and Strategy patterns are identical, the intent is quite different. Most important is the Context class in the Strategy design. It does not keep track of a current state as does the State pattern.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

//Context Participant
package
{
	import flash.display.Sprite;
 
	public class Context extends Sprite
	{
		private var bring:IStrategy;
		private var bringObj:Sprite=new Sprite();
 
		public function Context(bring:IStrategy)
		{
			this.bring = bring;
		}
 
		public function bringLoad(url:String):Sprite
		{
			bringObj.addChild(bring.contentLoader(url));
			return bringObj;
		}
	}
}

In some respects the Context class in the Strategy resembles a factory because the request for strategies is made through the Context, but it does not really instantiate a concrete strategy as a factory would. The Sprite instantiated in the Context (bringObj) acts as a carrying container to return the requested strategy to the requesting class (Client in this case.) However, no concrete strategies are created.

The IStrategy interface has a single method to be implemented. The method is used to pass requests back to the requesting class.

1
2
3
4
5
6
7
8
9

package
{
	import flash.display.Sprite;
	public interface IStrategy
	{
		function contentLoader(url:String):Sprite;
	}
 
}

The IStrategy interface leaves a lot of flexibility for adding more concrete strategies for returning Sprite (or Sprite encased) materials to the client.

Concrete Strategies

Finally, the two concrete strategies both load external content. The first is an image/SWF loader and the latter is a text/xml file loader. It is simple and flexible:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

//Graphic and SWF Loader
package
{
	import flash.net.URLRequest;
	import flash.display.Loader;
	import flash.display.Sprite;
 
	class BringGraphic implements IStrategy
	{
		private var urlReq:URLRequest;
		private var loader:Loader;
		private var objNow:Sprite=new Sprite();
 
		public function contentLoader(url:String):Sprite
		{
			urlReq = new URLRequest(url);
			loader=new Loader();
			loader.load(urlReq);
			objNow.addChild(loader);
			return objNow;
		}
	}
}

The BringText class required an event handler function for insuring that the text was completely loaded. The event handler method is a convenient place to put the TextFormat object and properties. Once the text is pulled out of the text or xml file and placed into the formatted text field, it was packed up and put into a Sprite object ready to return to the Client.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

//Text and XML Loader
package
{
	import flash.display.Sprite;
	import flash.text.TextField;
	import flash.text.TextFormat;
	import flash.net.URLLoader;
	import flash.net.URLRequest;
	import flash.events.Event;
 
	public class BringText implements IStrategy
	{
		private var textContainer:Sprite=new Sprite();
		private var urlNow:URLRequest;
		private var txtLoader:URLLoader=new URLLoader();
		private var txtFld:TextField=new TextField();
		private var txtFormat:TextFormat=new TextFormat();
		private var uLoader:URLLoader;
 
		public function contentLoader(url:String):Sprite
		{
			urlNow=new URLRequest(url);
			txtLoader.addEventListener(Event.COMPLETE, addTxtFld);
			txtLoader.load(urlNow);
			return textContainer;
		}
 
		private function addTxtFld(e:Event):void
		{
			uLoader=URLLoader(e.target);
			txtFormat=new  TextFormat();
			txtFormat.font="Verdana";
			txtFormat.size=24;
			txtFormat.color=0x000000;
			txtFld.defaultTextFormat=txtFormat;
			txtFld.multiline=true;
			txtFld.width=300;
			txtFld.height=250;
			txtFld.wordWrap=true;
			txtFld.x=10,txtFld.y=90;
			txtFld.text=uLoader.data;
			textContainer.addChild(txtFld);
		}
	}
}

As noted, this pattern is simple, but very handy. The classes are reusable and simple to update and change. Further, adding more classes is just as easy, and that means updating the mobile application is simple.

On to Flex and Flash Builder

The next step is to take the ActionScript 3.0 in this mobile application and do the same thing in Flash Builder. The Client class will have to reside in an MXML file instead of an AS file. Next up, we’ll see how to take this app and bundle it up using Flash builder. I’d also like to see other simple Flex/Flash Builder mobile design pattern examples that might help our readers—even implementations of this code in the Flash Builder IDE.

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

As you can see, far from being a herd of cavemen with clubs, each of the members of the platoon has a specific role. A lieutenant with the aid of an experienced platoon sergeant runs the show. A radio operator keeps in contact with the higher-level organization (company) and other assets than can be brought to bear (e.g. artillery and air support). Broken down into four squads, 3 rifle squads and a weapons squad, the organization is fairly generic of those in the US Army and is instructive for some more complex (and realistic) applications in Flex and Flash.

What Varies?

To get started, it helps to have some kind of perspective on the problem. If we look at the basic military hierarchy, we can get an idea:

Can the simulation be expanded even to company size? The sample platoon is set up for 38 soldiers, and the Company for between 62-190, depending on specialized assignments. These are only the combat units and do not include such service and support units as medics, transport, military police and other service units.

In looking at Figure 1, we can immediately see that roles vary. Put another way, their behaviors vary. Initially, a single Warrior class was used and subclasses of Red and Blue classes made up two opposing sides. However, other than the appearance of their movie clip icons, they were identical. If we added more and more functions, we’d have to override virtually ever other method. So, we need another way.

For this round of development, we need to think about one of the first principles of design patterns,

Separate what varies from what stays the same and encapsulate what varies.

Since we’ve identified that behaviors vary because of the different roles (not a bunch of undifferentiated cavemen with clubs), we’ll start with the weapons and firing behavior. We’ll put the behaviors into an interface and set up implementations of the different weapons. At the same time, we’ll set up the Warrior class so that they can use the different weapons through composition. That is, each instance of each subclass will have a different weapon to use instead of the weapon and its related behavior as an integral part of the particular Warrior class.

Sound On!

To see where all of this is leading turn up your sound and click the Play button. You will see different organizational options when you press the buttons along the top. When you click on the individual “soldiers”, they will play a sound representing their weapons. In the case of the officer and NCO’s, the entire unit’s weapons fire simultaneously representing commanded fire. Because the anti-armor and machine gun units require two people to use the weapons, clicking either of the two sprites serve to fire the weapon. After you’ve had a look, download the files—only selected few were placed in this post.

To kick things off we’ll be looking at a very simplified Warrior class and an interface for firing weapons shown in the following code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

//Warrior abstract class
package
{
	import flash.display.Sprite;
 
	//Abstract class. Do not instantiate
 
	public class Warrior extends Sprite
	{
		protected var fire:Fire;
		//protected var movement:Movement;
		//protected var comm:Communicate;
	}
}
 
//Encapsulating behaviors
package
{
	interface Fire
	{
		function fireWeapon():void;
	}
}

Those two elements should be viewed as structuring elements that help guide the development of the program. The Warrior abstract class includes a reference to the Fire interface and the set of behaviors that will be derived from implementations of that interface. The concrete Warrior classes will not derive their behaviors from the parent class but from the aggregate relationship between the Warrior interface (abstract class) and the Fire interface. (You can see two commented out variables, movement and comm that I’ll be referring to in a later post, but they can be ignored for the rest of this post.)

Different Characters and Behaviors

If you’ve ever been admonished to differentiate between a bad action and a bad person you’ll understand what’s going on here. The person belongs to the Warrior class and the action belongs to the Fire interface. They have the relationship shown in Figure 2:

Figure 2: Class diagram of Warrior and Fire

As you can see in Figure 2, all of the algorithms for weapons actions are encapsulated in the Fire implementations. The Warrior subclass objects get their behaviors through the Warrior interface through the Fire interface.

Marrying the Warrior to the Action

In bringing together the behavior and character, you’ll be glad to know there’s no bridezilla in the coupling. In fact, to quote another fundamental OOP principle,

Objects should be loosely coupled.

So even better, by having loosely coupled objects, when something changes, there won’t be a collapse in the entire system just in case a particular coupling doesn’t work as planned.

In Part I of The Wrong Way Warrior, the developer used movement with buttons to illustrate how each instance inherited the ability to move on the screen. This time around, the developer is demonstrating how the different types of soldiers carry out a behavior—firing a weapon—that is composed into his object through aggregation. So, instead of shooting up the screen, this time the developer decided to use sound effects of the different weapons. Also, to fire the weapons, instead of having another set of buttons, clicking on individual concrete Warrior objects launches the appropriate sound effects.

As noted above, the concrete Warrior objects are coupled with a Fire implementation, and as you will see, they’re very similar. In that respect they’re interchangeable; and that’s just what we want. Starting off, the following listings show the Rifleman (RifleMn) character and the FireRifle behavior.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

//Creates concrete Warrior instance
package
{
	import flash.display.Sprite;
	import flash.events.MouseEvent;
 
	public class RifleMn extends Warrior
	{
		//Rifleman is movie clip in Library
		private var rm1:Sprite=new Rifleman();
 
		public function RifleMn(fx:uint,fy:uint):void
		{
			rm1.x = fx,rm1.y = fy;
			rm1.addEventListener(MouseEvent.CLICK, fireNow);
			addChild(rm1);
		}
 
		private function fireNow(e:MouseEvent):void
		{
			fire = new FireRifle();
			fire.fireWeapon();
		}
	}
}
 
//Implements Fire behavior
package
{
	public class FireRifle implements Fire
	{
		import flash.media.Sound;
		import flash.media.SoundChannel;
		import flash.net.URLRequest;
 
		private var url:String = "WeaponSounds/M16.mp3";
		private var weapon:SoundChannel;
 
		public function fireWeapon():void
		{
			var urlReq:URLRequest = new URLRequest(url);
			var gun:Sound=new Sound();
			gun.load(urlReq);
			weapon = gun.play();
			trace("Firing M16--1 shot burst");
		}
	}
}

The concrete Warrior selects a movie clip that represents its character first. Typed as a Sprite, it is used as a clickable event generator. In this case, the MovieClip object is named, Rifleman. The Rifleman instance is event-linked to a function fireNow() which then uses the fire object inherited from the parent class—Warrior. Using the fire object, the program instantiates the particular implementation of the behavior. In this case, it wants an instance of FireRifle. Keep in mind that fire inherited from Warrior is typed as a Fire object—only committing to the interface. This allows any implementation of the interface and its methods.

In looking at the Fire implementation of FireRifle, it basically sets up the sound file that is played. However, it only represents any algorithm that could be placed there instead. For example, it could be used in an algorithm to measure the expenditure of force against a target and keep track of the amount of ammunition a concrete Warrior instance expends and has remaining.

When you download and look at the different classes, you’ll see they’re pretty similar. However, some characters, like the Lieutenant, have a much more robust use of the Fire implementations as you can see in the following listing:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

package
{
	import flash.display.Sprite;
	import flash.events.MouseEvent;
 
	public class Lieutenant extends Warrior
	{
		//Lieut is movie clip in Library
		private var lt1:Sprite=new Lieut();
 
		public function Lieutenant(fx:uint,fy:uint):void
		{
			lt1.x = fx,lt1.y = fy;
			lt1.addEventListener(MouseEvent.CLICK, fireNow);
			addChild(lt1);
		}
 
		private function fireNow(e:MouseEvent):void
		{
			//Fire Personal Weapon
			fire = new FireRifle();
			fire.fireWeapon();
 
			//PlatoonFire
			squadFire();
			weaponsSquadFire();
			squadFire();
			squadFire();
		}
 
		private function squadFire():void
		{
			//Fire Team 1
			fire.fireWeapon();
			fire.fireWeapon();
			fire = new FireSAW();
			fire.fireWeapon();
			fire = new FireGrenade();
			fire.fireWeapon();
 
			//Fire Team 2
			fire = new FireRifle();
			fire.fireWeapon();
			fire.fireWeapon();
			fire = new FireSAW();
			fire.fireWeapon();
			fire = new FireGrenade();
			fire.fireWeapon();
		}
 
		private function weaponsSquadFire():void
		{
			fire=new FireMG();
			fire.fireWeapon();
			fire.fireWeapon();
			fire=new FireRocket();
			fire.fireWeapon();
			fire.fireWeapon();
		}
	}
}

As you can see, the Lieutenant fired every weapon in the platoon, as did the Platoon Sergeant. This illustrates how flexible this design is. Because the behaviors are separated from the objects that use them, you can put them in any combination you want.

The Client

If you look at the Client carefully, you’ll see no reference at all to the Fire operations. That’s because the concrete Warrior objects all access Fire behaviors themselves. There’s no reason (nor would you want one!) to implement a concrete Fire object from the Client directly. Client constructor creates buttons used to display different arrangements of the troops. The bigger problem was getting rid of one configuration when another had been placed on the stage. Keith Peters provided a handy algorithm for clearing all children, and so I put it in the piedPiper() function that clears everything—including the buttons! So the piedPiper() method replaces the buttons after blowing them and the rest of the children off the stage.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170

package
{
	import flash.display.Sprite;
	import flash.events.MouseEvent;
	import fl.controls.Button;
 
	public class Client extends Sprite
	{
		private var rocketBtn:Button=new Button();
		private var mgBtn:Button=new Button();
		private var ftBtn:Button=new Button();
		private var sqBtn:Button=new Button();
		private var hqBtn:Button=new Button();
 
		private var lieut:Warrior;
		private var platoonSgt:Warrior;
		private var radio:Warrior;
		private var sqLdr:Warrior;
 
		private var tmLdr:Warrior;
		private var sawMan:Warrior;
		private var grenMan:Warrior;
		private var rifMan:Warrior;
 
		private var tmLdr2:Warrior;
		private var sawMan2:Warrior;
		private var grenMan2:Warrior;
		private var rifMan2:Warrior;
 
		private var mgunner:Warrior;
		private var asstMgunner:Warrior;
 
		private var rocket:Warrior;
		private var asstRocket:Warrior;
 
		public function Client()
		{
			ftBtn.addEventListener(MouseEvent.CLICK, fireTeam);
			ftBtn.label = "FireTeam";
			ftBtn.x = 10,ftBtn.y = 10;
			addChild(ftBtn);
 
			sqBtn.addEventListener(MouseEvent.CLICK, squad);
			sqBtn.label = "Squad";
			sqBtn.x = 120,sqBtn.y = 10;
			addChild(sqBtn);
 
			mgBtn.addEventListener(MouseEvent.CLICK, mgCrew);
			mgBtn.label = "Machine Gun";
			mgBtn.x = 230,mgBtn.y = 10;
			addChild(mgBtn);
 
			rocketBtn.addEventListener(MouseEvent.CLICK, rocketCrew);
			rocketBtn.label = "Anti Armor";
			rocketBtn.x = 340,rocketBtn.y = 10;
			addChild(rocketBtn);
 
			hqBtn.addEventListener(MouseEvent.CLICK, hq);
			hqBtn.label = "Headquarters";
			hqBtn.x = 450,hqBtn.y = 10;
			addChild(hqBtn);
		}
 
		private function fireTeam(e:MouseEvent)
		{
			piedPiper();
 
			tmLdr = new TeamLdr(300,424);
			addChild(tmLdr);
 
			rifMan = new RifleMn(428,338);
			addChild(rifMan);
 
			sawMan = new SAW(480,424);
			addChild(sawMan);
 
			grenMan = new Grenadier(428,512);
			addChild(grenMan);
		}
 
		private function squad(e:MouseEvent)
		{
			piedPiper();
 
			sqLdr = new SquadLdr(82,300);
			addChild(sqLdr);
 
			tmLdr = new TeamLdr(300,424);
			addChild(tmLdr);
 
			rifMan = new RifleMn(428,338);
			addChild(rifMan);
 
			sawMan = new SAW(480,424);
			addChild(sawMan);
 
			grenMan = new Grenadier(428,512);
			addChild(grenMan);
 
			tmLdr2 = new TeamLdr(420,162);
			addChild(tmLdr2);
 
			rifMan2 = new RifleMn(548,76);
			addChild(rifMan2);
 
			sawMan2 = new SAW(600,162);
			addChild(sawMan2);
 
			grenMan2 = new Grenadier(548,250);
			addChild(grenMan2);
		}
 
		private function mgCrew(e:MouseEvent)
		{
			mgunner = new MG(520,500);
			addChild(mgunner);
			asstMgunner = new AssistantMG(550,570);
			addChild(asstMgunner);
		}
 
		private function rocketCrew(e:MouseEvent)
		{
			rocket = new RocketMan(650,250);
			addChild(rocket);
			asstRocket = new AssistRocket(700,300);
			addChild(asstRocket);
		}
 
		private function hq(e:MouseEvent)
		{
			lieut = new Lieutenant(132,98);
			addChild(lieut);
			platoonSgt = new PltSgt(66,188);
			addChild(platoonSgt);
			radio = new RadioMan(194,188);
			addChild(radio);
		}
 
		private function clearFireTeam()
		{
			removeChild(tmLdr);
			removeChild(sawMan);
			removeChild(grenMan);
			removeChild(rifMan);
		}
 
		private function clearSquad()
		{
			clearFireTeam();
			removeChild(sqLdr);
			removeChild(tmLdr2);
			removeChild(sawMan2);
			removeChild(grenMan2);
			removeChild(rifMan2);
		}
 
		private function piedPiper()
		{
			while (numChildren > 0)
			{
				removeChildAt(0);
			}
			addChild(ftBtn);
			addChild(sqBtn);
			addChild(mgBtn);
			addChild(rocketBtn);
			addChild(hqBtn);
		}
	}
}

If you run the program from within the Flash/Flex IDE, you should be able to see trace statements in the Output window as well to tell you what’s going on—in addition to the sound effects.

The Next Steps

I doubt there’s anyone who’s read this blog who doesn’t recognize the design pattern in use; so I won’t go into that. However, this project is yet to be completed. That will come in future posts. Now that we’re on the right track, we (that means you as well) can envision what other behaviors—or class of behaviors and their accompanying algorithms—could be added to the current set.

If you’re interested in game development, I hope that this little demonstration has shown the practicality of using design patterns and how easy they can make it. This is especially true as your projects become more complex. You might also want to review Chapter 13 of our book where we cover the Symmetric Proxy Pattern. There you will find a solution to the problem of simultaneous movement and multi-person play over the Internet using Flash Media Server. Setting up a platoon or even squad level game using simultaneous movement would be a lot of fun, and you could use several of the design patterns we discussed on this blog and in our book.

Swiss Army Knife of Design Patterns: The Strategy Pattern

The Strategy pattern defines a family of algorithms, encapsulates each and makes them interchangeable. Figure 1 shows the basic look of the Strategy pattern:

Figure 1: Strategy pattern Class Diagram

An interface (Strategy) describes the abstract signatures for the algorithm to be used with a family of algorithms. The key here is understanding that when developing a Strategy pattern that you need to think through the implications of the abstract methods you’ve got as part of a cluster of related algorithms. Given that this example only has a single Concrete Strategy class, you can assume that you have an opportunity to add more concrete strategies, and at the end of the post I’ll suggest a few.

The Strategy and Its Subclasses

In developing projects using design patterns, you can start in a lot of different places, and I seem to have started in all of them. For this one, I started with the Client and imagined what I wanted to request. Keeping in mind that the only reason a Client should change is to make a request.

The Client is the gimme class.

Once figuring out what I wanted by fiddling around with the Client, I decided on the Strategy pattern. All I needed just for this particular application was for it to load an SWF file. However, I was thinking, what if I wanted to load materials from XML or text files? I’d have to use slightly different algorithms but different enough for different concrete strategies. So, the Strategy pattern looked to be a good place to add algorithms for loading XML and text files if somewhere down the road I wanted more flexibility in what I could load.

So first off, let’s look at the Strategy interface (an abstract class in this case) and then look at the concrete class.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

//Abstract class: Strategy Interface
package
{
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class ILoadMaster extends Sprite
	{
		public function loadStuff(url:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
	}
}

As you can see it’s got a single abstract method with a single string parameter. The string parameter is for the name (URL if you wish) of the file to be loaded. The implementation of this abstract class loads a SWF or graphic files.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

//Concrete Strategy
package
{
	import flash.net.URLRequest;
	import flash.display.Loader;
 
	class PixLoader extends ILoadMaster
	{
		private var urlReq:URLRequest;
		private var loader:Loader;
 
		override public function loadStuff(url:String):void
		{
			urlReq = new URLRequest(url);
			loader=new Loader();
			loader.load(urlReq);
			addChild(loader);
		}
	}
}

The string parameter is passed to the URLRequest class initializer, which in turn is used in the load() parameter. All in all it’s pretty simple, but it resides in a loose pattern and is easy to extend.

The Simple Beauty of the Context Class

In most of the Strategy patterns I’ve written, the Context class has subclasses. If you peruse the Web, you’ll find lots of examples of the Strategy pattern using multiple Context subclasses. (In our book this was the case and in one of the blog posts as well.) In retrospect, the Context class left in its original concrete form has much to offer. It’s like a polymorphism machine. The following Context class follows the GoF model (as does the class diagram in Figure 1).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

//Context class
package
{
	import flash.display.Sprite;
 
	public class Context extends Sprite
	{
		private var lm:ILoadMaster;
 
		public function Context(lm:ILoadMaster):void
		{
			this.lm = lm;
		}
 
		public function doLoad(url:String):void
		{
			lm.loadStuff(url);
			addChild(lm);
		}
	}
}

Even though the Context class is concrete, everything about it is abstract. The references are to ILoadMaster (the Strategy interface) and an unnamed string parameter. So you could add as many concrete strategies as you want, and they could all pass though the Context class without a concrete reference at all.

The Client Requests a Context

Finally, the Client requests whatever it wants. The Client makes a request through the Context class by instantiating an ILoadMaster instance in the instantiation process. The line,

contextDy=new Context(new PixLoader());

(in the seeNow() method), sends the request to the concrete strategy class. The Context passes the request on to the concrete strategy without knowing what concrete strategy is being requested. As long as the correct format is observed, the Context is perfectly happy.

Keeping in mind that you can make the requests any way you want the following shows how the requests were made using a List component in the version I did. However, go ahead and use any request mechanism you want.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

//Client class
package
{
	import flash.display.Sprite;
	import fl.controls.List;
	import fl.data.DataProvider;
	import fl.events.ListEvent;
 
	public class Client extends Sprite
	{
		private var context:Context=new Context(new PixLoader());
                private var contextDy:Context;
		private var list:List;
		private var lunchBucket:DataProvider;
		private var swf:String;
		private var container:Sprite=new Sprite();
 
		public function Client()
		{
			setMenu();
			context.doLoad("swf/p0.swf");
			container.x=180,context.y=0;
			container.addChildAt(context,0);
			addChild(container);
		}
 
		private function setMenu():void
		{
			lunchBucket=new DataProvider();
			lunchBucket.addItem( { label: "Liskov Substitution", data:"p1.swf" } );
			lunchBucket.addItem( { label: "Program to Interface", data:"p2.swf" } );
			lunchBucket.addItem( { label: "Favor Composition",  data:"p3.swf" } );
			lunchBucket.addItem( { label: "Encapsulate What Varies", data:"p4.swf" } );
			lunchBucket.addItem( { label: "Loosely Coupled Objects", data:"p5.swf" } );
			lunchBucket.addItem( { label: "Open/Closed", data:"p6.swf" } );
			lunchBucket.addItem( { label: "Dependency Inversion",  data:"p7.swf" } );
			lunchBucket.addItem( { label: "Least Knowledge Principle",data:"p8.swf" } );
			lunchBucket.addItem( { label: "Hollywood Principle",data:"p9.swf" } );
			lunchBucket.addItem( { label: "Only 1 Reason to Change",data:"p10.swf" } );
			list=new List();
			list.setSize(150,200);
			list.x = 16,list.y = 64;
			list.dataProvider = lunchBucket;
			addChild(list);
			list.addEventListener(ListEvent.ITEM_CLICK,seeNow);
		}
 
		private function seeNow(e:ListEvent):void
		{
			container.removeChildAt(0);
			contextDy=new Context(new PixLoader());
			swf="swf/"+e.item.data;
			contextDy.doLoad(swf);
			container.addChildAt(contextDy,0);
		}
	}
}

You will need a folder named “swf” for the SWF files and use the naming convention shown in the lunchBucket DataProvider. (Of course, you can use any naming convention you want; just change the code in the DataProvider if you do so.) Also, if you’re using Flash, you’ll need a copy of the List component in the Library.

You’re On Your Own

The purpose of this little design pattern is to make it simple yet practical. Take it to work and see if it comes in handy when you have a project loading external files. The family of algorithms I had in mind when I decided to use this pattern is the one of loadable external data such as data from XML or text files. I believe that this pattern will do the job.

I would be delighted to see extensions of more concrete strategies using this pattern. Also I think it’s probably a good exercise for learning more about design patterns in ActionScript 3.0. Of course if you’d like to make any artful graphic improvements to my efforts, those would be a delight as well.

If this entry evokes a sense déjà vu, you’d be half right. It is not another jibe to condemn conditional statements, but instead it is a discovery of another pattern where you can eliminate them. The consequences listed by Gamma, et al for the Strategy pattern includes,

Strategies eliminate conditional statements.

While I am quite familiar with the fact that the State design pattern eschews conditional statements, I was unaware that the Strategy pattern has the same feature. Rather, like everyone else I focused on the dictum, encapsulate the concept that varies when dealing with the Strategy pattern. Here I do not plan to re-hash what we covered in Chapter 11 of our book, but instead I want to look at a simple Strategy design pattern where no conditional statements are used. Also, I want to walk through a thought process when working on a simple application and show how flexible it is because of the Strategy design pattern.

It All Began with a simple MP3 Player

Creating an MP3 player in Flash is something I’ve done often and never gave it a second thought using the NetConnection and NetStream classes. However, recently I was working on one using the Sound and SoundChannel classes. Turning it on and off was trivial, but I learned that unlike the NetStream class, the SoundChannel class has no pause method. (NetStream has both toggle and non-toggle versions of pause methods.) The SoundChannel has a position property that returns the position of the MP3 file currently playing. By passing the position value to a variable and passing it to a play() method as a parameter, the play would resume where it left off. So building a player using either NetStream or SoundChannel is not rocket science.

However, suppose you decide to have a structure that could use either the NetStream or SoundChannel class. To that you might also add whether you wanted the MP3 to play on the NetStream as a progressive download or as streaming audio through Flash Media Server 3. All you have to change is the content of the algorithms to accommodate any of the three versions you envision. Of course you don’t want to dismantle all of the other work if you decide to change the program. You just need to change the algorithms.

The Abstract Architecture of a Strategy MP3 Player

When you get right down to it, you only need four algorithms:

• Start Play
• Stop Play
• Pause Play
• Unpause Play

Depending on what you have set up in the Client class for a UI and the types of classes you’re using to play the MP3 files, the details of the algorithms will vary, and you may even have a class to organize the Sound/SoundChannel or NetConnection/NetStream methods. For now, though, all I want is architecture to handle starting and stopping play and pause. This will also help reveal the structure of the Strategy design pattern. Figure 1 shows the Strategy pattern that is used in this example:

Figure 1: MP3 Player Strategy Design Pattern

The IPlayer interface is the Strategy portion of the pattern. All of the algorithms go into implementations of IPlayer, and so all we need will be four concrete strategies—one for each of the actions on the MP3 player. For this example, I’ll just use trace() statements to act as stand-ins for actual algorithms.

Context Class

The left part of the class diagram in Figure 1 is the Context participant in the pattern. As shown in the diagram, the Context class holds a reference to the Strategy (IPlayer) participant. That reference to the IPlayer can be seen in the following listing:

1
2
3
4
5
6
7
8
9
10
11
12
13

 
package
{
	public class Context
	{
		protected var player:IPlayer;
 
		public function doControl():void
		{
			player.control();
		}
	}
}

The reference is in typing the player instance as an IPlayer and then holding a reference to the control() method in the player. The control() method is an algorithm developed in the strategy implementations. The Context class has no idea what that reference to the player method will be but serves to make it available to a client and subclasses that inherit the Context class. In this case, four Context subclasses are created, one for each of the operations—playing, stopping play, starting pause, and turning pause off. The following listings show all of the classes that extend the Context class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

//Starter.as
package
{
	public class Starter extends Context
	{
		public function Starter()
		{
			player= new StartPlay();
		}
	}
}
 
//Stopper.as
package
{
	public class Stopper extends Context
	{
		public function Stopper()
		{
			player= new StopPlay();
		}
	}
}
 
//Pauser.as
package
{
	public class Pauser extends Context
	{
		public function Pauser()
		{
			player= new StartPause();
		}
	}
}
 
//UnPauser.as
package
{
	public class UnPauser extends Context
	{
		public function UnPauser()
		{
			player= new StopPause();
		}
	}
}

Each of the subclasses of Context instantiates a single strategy implementation, and no reference is made to the strategy’s class key method. As a result, the design pattern demonstrates a high degree of loose coupling.

The Strategy Interface and Implementations

The right side of the Strategy class diagram (Figure 1) shows the interface and implementations of the Strategy interface (IPlayer). Each of the algorithms is developed in the concrete strategies to be accessed by a client through the Context class. The algorithms can be as simple or complex as required by the goals of the application. In this particular case, the “algorithms” are nothing more than trace statements that are placeholders for whatever algorithm one wishes to use. For the practical programmer this means that when change occurs, all you need to do is to change the algorithm without worrying about conflict with other parts of the program. The following shows the Strategy interface (IPlayer) and its four concrete classes.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

//IPlayer.as
package
{
//Strategy interface
	public interface IPlayer
	{
		function control():void;
	}
}
 
//StartPlay.as
package
{
	//Concrete Strategy
	public class StartPlay implements IPlayer
	{
		//var playMP3:PlayTune
		public function control():void
		{
			trace("Play tune");
		}
	}
}
 
// StopPlay.as
package
{
	//Concrete Strategy
	public class StopPlay implements IPlayer
	{
		//var playMP3:PlayTune
		public function control():void
		{
			trace("Stop play");
		}
	}
}
 
//StartPause.as
package
{
	//Concrete Strategy
	public class StartPause implements IPlayer
	{
		//var playMP3:PlayTune
		public function control():void
		{
			trace("Start pause");
		}
	}
}
 
// StopPause.as
package
{
	//Concrete Strategy
	public class StopPause implements IPlayer
	{
		//var playMP3:PlayTune
		public function control():void
		{
			trace("Stop pause");
		}
	}
}

As you can see, each of the concrete classes has a commented line with a reference to:

playMP3:PlayTune

This line represents some reference to a class that handles either the Sound/SoundChannel or NetConnection/NetStream classes.

The Client

The Gang of Four note that [a] context forwards requests from its clients to its strategy, and that [clients] usually create and pass a ConcreteStrategy object to the context. This is exactly what we have done with the Client class. As you can see in the Client.as listing below all references are to the Context class or one of its extensions where the specific algorithm from the Strategy classes are referenced via the concrete context class and not the strategy implementation.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

//Client.as
package
{
	import flash.display.Sprite;
 
	public class Client extends Sprite
	{
		private var musicMaster1:Context;
		private var musicMaster2:Context;
		private var musicMaster3:Context;
		private var musicMaster4:Context;
 
		public function Client()
		{
			musicMaster1=new Starter();
			musicMaster1.doControl();
 
			musicMaster2=new Stopper();
			musicMaster2.doControl();
 
			musicMaster3=new Pauser();
			musicMaster3.doControl();
 
			musicMaster4=new UnPauser();
			musicMaster4.doControl();
 
		}
	}
}

The doControl() method from the Context class is a reference to the IPlayer’s sole method, control(). However, as you can see the Client accesses the Strategy through the Context enabling a loose but effective connection between the client and the algorithms in the program.

When you test the Client, you will see each of the “algorithm’s” results.

Play tune
Stop play
Start pause
Stop pause


Each of the instantiations of the different Context classes could just as well be functions fired by a button or some other UI. Also, note that not a single conditional statement can be found in the entire program. A selection from the Client assumes a certain response with no ifs, ands or buts. As a result, there’s no conditional linkage to get tangled up in if you decide to make a change.

Do-It-Yourself MP3 Player

Now that you have the basic architecture for an MP3 player, we’d like to see if any of you can actually put something together that will play/pause/stop/unpause an actual MP3 application using this pattern. If you’re new to Design Patterns, it’ll be a chance to see if you can use them to accomplish a task beyond the abstract traces done in this example. If you’re an old hand with Design Patterns, it’s a little toy problem to solve like a crossword puzzle. The challenge is to do it in the design pattern provided. You can use either Flex or Flash (the example was developed in Flex), and the Client class should have all of the UIs and instances you’d normally have. You can add classes to support the client and you need to change all of the algorithms in the Strategy concrete classes, but it must maintain the basic class structure shown.

If you’re interested in the Strategy patterns in ActionScript 3.0, here’s an article by Sean Moore that I think you’ll like:http://www.insideria.com/2008/11/exploring-the-strategy-design.html