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.

Adding one object to another object in ActionScript 3.0 takes many forms, but when it comes to adding an object to a Sprite, a simple method is to use the addChild() method. The statement,

      mySprite.addChild(myObject);

does the trick. By referencing all drag methods to the Sprite instance, you can drag the Sprite and anything that’s been added to it. The following program takes care of the initial query I had—it allows you to drag a video.

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

package
{
	import flash.display.Sprite;
	import flash.media.Camera;
	import flash.media.Video;
	import flash.events.MouseEvent;
 
	public class DragVid extends Sprite
	{
		private const WIDE:uint=320;
		private const HIGH:uint=240;
		private var vidSled:Sprite=new Sprite();
		private var vid:Video = new Video(WIDE,HIGH);
		private var cam:Camera = Camera.getCamera();
 
		public function DragVid()
		{
		setMedia();
		vidSled.addEventListener(MouseEvent.MOUSE_DOWN,doDrag);
		vidSled.addEventListener(MouseEvent.MOUSE_UP,unDrag);
		}
 
		private function setMedia():void
		{
			cam.setMode(WIDE,HIGH,20);
			cam.setQuality(0,100);
			vid.smoothing=true;
			vid.attachCamera(cam);
			vid.x = 100,vid.y = 100;
			addChild(vidSled);
			vidSled.addChild(vid);
		}
 
		private function doDrag(e:MouseEvent):void
		{
			this.startDrag();
		}
 
		private function unDrag(e:MouseEvent):void
		{
			this.stopDrag();
		}
	}
}

You may notice that no net elements are included, such as NetConnection or NetStream. However, they could be added for anything from a video playback to a Flash Media Interactive Server application. The objects associated with the dragging lose none of their functionality. As you can see the code sets the mode and quality of the Camera instance. Likewise, the Video instance takes advantage of mipmapping by setting the smoothing property to true.

Hook up your camera and give it a try by clicking the “Play” button:

Figure 1 shows this simple process. The hand icon in the upper right corner of the video object shows where the mouse has seized the image and is dragging the video embedded in the Sprite object.

Figure 1: Video hitchhiking on a Sprite gets dragged as startled subject looks on

Originally, I added a graphic in the Sprite to provide a visual background, but that was just added bling with no function other than distracting readers from the purpose of the Sprite. However, for those who like backdrops, you can add one using the graphics property and methods in the Sprite object.

What Varies?

For some food for thought for Part II of this post, get the Magic Table (if you don’t already have it) to determine what variation you need to control. That will give you a guide to the design pattern we can use. (Hint: We do not need to vary the sole instance of a class).

Essentially, here’s what we need to figure out:

What varies that we need to deal with when creating any dragable object?

Once that question is answered, we can begin working on the program using the design pattern that takes into account the variation. In the meantime, we’d like to get your comments on both the variation and the task of dragging objects using OOP and ActionScript 3.0.

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.

Other than a handful of developer/designers, most designers aren’t going to become competent with ActionScript 3.0, let alone OOP or design patterns—just like I’m never going to be a competent designer or artist. So I was thinking an interesting project for this blog would be to develop some “Clip Code” for artists. However, I’m not sure what kind of code they’d need. Most of the “Clip Art” that I use is from photographs, but while I know the kind of artwork I need, I don’t know what kind code graphic designers need.

In the same way that I don’t want to have shoddy graphics or photographs (I can do that myself), the “Clip Code” I have in mind is grounded in good but simple design patterns and OOP that artists can use. So, I’d like to throw that one out to the readers of this blog for ideas of what would be useful to graphic designers.

Animation and Dante’s 10th Circle of ActionScript Hell

We all remember from our Italian Literature course that Dante Alighieri’s Divine Comedy describes hell as having nine circles—the last circle being reserved for treason. Were Dante an ActionScript developer, he’d have a 10th Circle for those animators who spread 50 little ActionScript code blocks all over the timeline in different frames and on different layers. (In the last mention of Dante’s inferno on this blog, we only got to the 9th circle.)

Don’t get me wrong. I love animation, and in fact I got Flash initially so that I could do animations on the Web. When first working with Flash, I ran out and got Tony White’s The Animator’s Workbook: Step-by-Step Techniques of Drawn Animation, and I was delighted with what Flash could do following traditional animation techniques. (Joe Cartoon is still one of my heroes.)

What drives me nuts is using animations for some little effect that will be forgotten after one or two views that screw up an entire application. I’m convinced that animation is the sine qua non of Flash, and so I would never suggest that it be reduced in any way. Rather, I think that animation in movie clips needs to be controlled outside of the confines of code embedded in frames and the timeline. For example, pressing the green Play button shows a simple movie clip added to an existing fire-the-weapon animation:

The relevant code for the operation is the following:

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

package
{
	import flash.display.Sprite;
	import flash.media.Sound;
	import flash.media.SoundChannel;
	import flash.net.URLRequest;
	import flash.events.MouseEvent;
	import flash.display.MovieClip;
	import flash.events.Event;
 
	public class Client extends Sprite
	{
		private var m249:MovieClip=new M249();
		private var mc:MovieClip;
		private var weapon:SoundChannel;
		private var url:String = "M249.mp3";
 
		public function Client()
		{
			m249.addEventListener(MouseEvent.CLICK,fireWeapon);
			m249.x = 50,m249.y = 60;
			addChild(m249);
			m249.gotoAndStop(1);
		}
 
		private function fireWeapon(e:MouseEvent):void
		{
			playOnce(m249);
			var urlReq:URLRequest = new URLRequest(url);
			var gun:Sound=new Sound();
			gun.load(urlReq);
			weapon = gun.play();
		}
 
		private function playOnce(mc:MovieClip)
		{
			this.mc=mc;
			this.mc.play();
			this.mc.addFrameScript(mc.totalFrames-1,reset);
		}
 
		function reset()
		{
			this.mc.gotoAndStop(1);
		}
	}
}

The m249 instance is of a movie clip that uses a shape tween to simulate muzzle flashes. (The sound routine was borrowed from another application.)

Initially, the problem I encountered, and I am sure all Flash animators encounter, is the requirement of keeping at least some code on the timeline. After a few false starts, I was able to control it with relatively simple functions with no timeline code. The above code simply represents the possibility of allowing animators to do whatever they want while not worrying about code.

Thanks to Steve Mathews and Colin Holgate who introduced me to the undocumented MovieClip.addFrameScript(), I was able to stop the looping movie clip after a single iteration. My initial solution used Event.ENTER_FRAME, but I liked that offered up by Steve and Colin better. Anyway, there’s a good post on addFrameScript() at Troy Gardner’s blog if you’d like to learn more about it. Like all undocumented code, I’m often at a loss to understand why it’s undocumented.

The huge advantage of an approach that is not in anyway tied to the timeline is re-usability. If all of the coding is external to the development of the movie clip with the animation, there’s less worry about getting tangled up in unknown code lurking on the timeline. You can reuse the animating movie clips with the assurance that what you see is what you get and you can add code without tangling it up with code tucked away in some unseen layer on an unseen frame.

For complex animations, planning is essential, and I’d like to find out what animators would find useful included in the examples and projects examined on this blog. Like artist, animators work is some kind of context and I’d like to refactor animations so that no timeline code is included in the application of the animations.

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.

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.

Perhaps the biggest problem with design patterns is that they’re difficult to learn and other simpler solutions are available. By simpler I’m referring to the fact that the programming and thought processes that go into the solutions are not as difficult. That’s true. However, in the long run, OOP and design patterns make programming much easier because the solutions lend themselves to revision and change. The larger and more complex that projects become, the more important design patterns are for maintaining and updating the program.

The Wrong Way Warrior

The first part of this post will look at a well-meaning OOP programmer who has been given the job of making a prototype for a battle game. To get started the programmer wants to kick things off by creating a Warrior class with several methods that represent what any warrior would have. So he puts the class together with the following methods:

• setID() – provide a unique ID for each warrior
• attackRight() – move character to the right
• attackLeft() – move character to the left
• retreatRight() – move character to the right
• retreatLeft() – move character to the left
• defend() – character does not move but fires weapon
• takeHit() – character is hit by enemy fire

By subclassing the Warrior class, the developer can build armies with each individual warrior having the properties of the Warrior. That makes perfect sense, and our programmer is creating an OOP-like object. The following listing shows the Warrior 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

package
{
	import flash.display.Sprite;
 
	public class Warrior extends Sprite
	{
		public var id:String;
 
		public function setID (idNow:String)
		{
			this.id = idNow;
		}
 
		public function attackRight ():void
		{
			this.x += 10;
		}
 
		public function attackLeft ():void
		{
			this.x-=10;
		}
 
		public function defend ():void
		{
			trace (this.id + " holds and fires weapon");
		}
 
		public function retreatLeft ():void
		{
			this.x-=10;
		}
 
		public function retreatRight ():void
		{
			this.x+=10;
		}
 
		public function takeHit ():void
		{
			this.rotation+=5;
		}
	}
}

Right away you might be thinking, “That’s not an abstract class, and it should be.” Well, it does not have a constructor, and giving the programmer his due, we can treat it as an abstract class by not instantiating it. (If that doesn’t work, we’ll blame it on the programmer.)

Subclassing Armies and Building MovieClip Warriors

For images of warriors, we’ll create a couple of movie clips representing a Red Army Warrior and a Blue Army Warrior. Both are placed in the Library and set for Export for ActionScript. One is named RedWarrior and the other, BlueWarrior and each is treated as a separate class. In this way the programmer can create as many instances of each as he wants for the Red and Blue armies. Figure 1 shows each of these creations:

Figure 1: Movie Clip Warrior Characters

Now that the characters are ready as addressable classes, the next step is to create subclasses from the Warrior class for each as shown in the following listings:

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

//Red Warrior
package
{
	import flash.display.Sprite;
 
	public class Red extends Warrior
	{
		//RedWarrior is a movie clip in Library
		private var red1:Sprite=new RedWarrior();
 
		public function Red (x1:uint,y1:uint)
		{
			red1.x = x1,red1.y = y1;
			addChild (red1);
		}
	}
}
 
//Blue Warrior
package
{
	import flash.display.Sprite;
 
	public class Blue extends Warrior
	{
		//RedWarrior is a movie clip in Library
		private var blue1:Sprite=new BlueWarrior();
 
		public function Blue(x1:uint,y1:uint)
		{
			blue1.x=x1,blue1.y=y1;
			addChild(blue1);
		}
	}
}

With concrete classes now for the warriors, including a sprite image representing both the red and blue sides, we’re all set to create a test bench to see if this prototype is ready to develop further. (Note that the programmer even typed the RedWarrior and BlueWarrior instances as Sprite ones—programming to the interface like he should be.)

Testing the Warriors

Now that the basics are completed, we can set up a test bench to see how the program works. All we need is a Client class that implements the warriors and see if the methods fly. This test incorporates buttons to fire the movement methods and trace firing weapons.

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

package
{
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	public class Client extends Sprite
	{
		private var redWarrior1:Warrior = new Red(20,30);
		private var blueWarrior1:Warrior = new Blue(400,30);
 
		private var redAttack:Button=new Button();
		private var redDefend:Button=new Button();
		private var redRetreat:Button=new Button();
		private var redHit:Button=new Button();
 
		private var blueAttack:Button=new Button();
		private var blueDefend:Button=new Button();
		private var blueRetreat:Button=new Button();
		private var blueHit:Button=new Button();
 
		public function Client ()
		{
			UIsetup ();
		}
 
		private function UIsetup ():void
		{
			redWarrior1.setID ("Red Hook");
			addChild (redWarrior1);
			blueWarrior1.setID ("Blue Moon");
			addChild (blueWarrior1);
 
			redAttack.addEventListener (MouseEvent.CLICK, redCharge);
			redDefend.addEventListener (MouseEvent.CLICK, redHold);
			redRetreat.addEventListener (MouseEvent.CLICK, redBugout);
			redHit.addEventListener (MouseEvent.CLICK, redWound);
			blueAttack.addEventListener (MouseEvent.CLICK, blueCharge);
			blueDefend.addEventListener (MouseEvent.CLICK, blueHold);
			blueRetreat.addEventListener (MouseEvent.CLICK, blueBugout);
			blueHit.addEventListener (MouseEvent.CLICK, blueWound);
 
			addChild (redAttack);
			redAttack.label = "Attack";
			redAttack.x = 20,redAttack.y = 300;
			addChild (redDefend);
			redDefend.label = "Defend";
			redDefend.x = 20,redDefend.y = 322;
			addChild (redRetreat);
			redRetreat.label = "Retreat";
			redRetreat.x = 20,redRetreat.y = 344;
			addChild (redHit);
			redHit.label = "Outch!";
			redHit.x = 20,redHit.y = 366;
 
			addChild (blueAttack);
			blueAttack.label = "Attack";
			blueAttack.x = 400,blueAttack.y = 300;
			addChild (blueDefend);
			blueDefend.label = "Defend";
			blueDefend.x = 400,blueDefend.y = 322;
			addChild (blueRetreat);
			blueRetreat.label = "Retreat";
			blueRetreat.x = 400,blueRetreat.y = 344;
			addChild (blueHit);
			blueHit.label = "Outch!";
			blueHit.x = 400,blueHit.y = 366;
		}
 
		private function redCharge (e:MouseEvent):void
		{
			redWarrior1.attackRight ();
		}
		private function redHold (e:MouseEvent):void
		{
			redWarrior1.defend ();
		}
		private function redBugout (e:MouseEvent):void
		{
			redWarrior1.retreatLeft ();
		}
		private function redWound (e:MouseEvent):void
		{
			redWarrior1.takeHit ();
		}
 
		private function blueCharge (e:MouseEvent):void
		{
			blueWarrior1.attackLeft ();
		}
		private function blueHold (e:MouseEvent):void
		{
			blueWarrior1.defend ();
		}
		private function blueBugout (e:MouseEvent):void
		{
			blueWarrior1.retreatRight ();
		}
		private function blueWound (e:MouseEvent):void
		{
			blueWarrior1.takeHit ();
		}
	}
}

That looks like a pretty big Client class, but all it does is to create a single instance of the red and blue warriors and lots of buttons to test the methods. The set of buttons on the left operate the Red Warrior and the ones on the right operate the Blue Warrior. Again, the programmer is no straw man—he programs to the interface to instantiate both the Red and Blue warriors. What we are questioning is how sustainable and expandable is this design?

When you test the program you should see the initial image shown in Figure 2:

Figure 2: Initial Positions of the Instances

Go ahead and test it. (You’ll find yourself having seconds of fun!). Everything works, and if you add additional characters, they’ll show up on the screen, but you’ll need separate sets of buttons to work them. However, that’s not the point. In developing the game all of the methods will be triggered either by program-generated events or a more sophisticated UI. So, for the time being just think of the buttons as tools for testing and not an integral part of the program.

What’s Wrong with this Picture?

First of all, it works. However, that’s not the point. The concept, “If it ain’t broke, don’t fix it” either fails to recognize it will break down the road or flees from innovation. (It’s sort of like the wanker without a girlfriend—he thinks this is a good as it gets.)

What will happen when this game is expanded? (Keep in mind the buttons are just a temporary testing device.) How do we accommodate changes in the weapons? What if we want to have special capabilities for each side? How can movement be enhanced (with rocket boots or magic capabilities). How can we make this game model more flexible?

My next post follows the Freemans’ lead and provides an alternative way to develop the game by introducing a design pattern. In the meantime, I’d like to hear readers’ ideas and comments on how to improve the development process. What would be a better way to start off creating a project like this? Are design patterns available to make this more sustainable? Expandable? Let’s hear what you think.

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.

Getting and Using the Data

Using a List component with ActionScript 3.0 code requires that a DataProvider object be assigned as a data source. The DataProvider object can be loaded with data in several ways—using the addItem() method, an array or XML files. For this project, I’ll be using the addItem() method, but you can substitute the other data loading techniques if you wish.

The DataProvider object requires two elements for this project. The first element is a label for the List component and the second is the URL to the video. The label element requires nothing more than a label indicating what video plays. Using Flash Media Interactive Server 3.5.2 (FMIS) and H. 264 format requires the following kind of reference:

    mp4: folderName/fileName.f4v

If you’re not familiar with Flash Media Server, no problem. This system works with a simple progressive download as well. So if you’d rather work with video files from a Web server, you can change the reference to:

      folderName/fileName.flv

(You cannot use F4V (H.264) files with progressive download).

So, the basic data-loading procedure is:

dataProvider.addItem( { label: "LabelName", data:" mp4: folderName/fileName.f4v " } );

In this first post, all I want to do is to look to see how the DataProvider is moved out of the Client and into a Factory Method design pattern.

Getting Data From the DataProvider Object

Initially, the Client contained the code for all operations involving the DataProvider. The List instance (list) was then assigned the DataProvider instance. The following shows code snippet the relevant features in the Client

1
2
3
4
5
6

var prague:DataProvider=new DataProvider();
prague.addItem( { label: "Panorama", data:"mp4:praguevid/panorama.f4v" } );
prague.addItem( { label: "Charles Bridge", data:"mp4:praguevid/charlesbridge.f4v" } );
prague.addItem( { label: "Old & New Town", data:"mp4:praguevid/newtown.f4v" } );
prague.addItem( { label: "Mucha Glass", data:"mp4:praguevid/mucha.f4v" } );
list.dataProvider = prague;

Once the data has been added to the List object, it is retrieved when an item in the list is clicked. The line,

   list.addEventListener(ListEvent.ITEM_CLICK,startPlay);

triggers a function used to get the URL for the video and play the selected video. The following operation shows how the selection and play events are handled:

1
2
3
4
5
6
7
8
9
10

private function startPlay(e:ListEvent):void
{
	if (ns)
	{
		//f4vid is a private string variable
		f4vid = e.item.data;
		vid.attachNetStream(ns);
		ns.play(f4vid);
	}
}

The key connection in the function is assigning the value of e.item.data to the string variable (f4vid). The data are used as the URL to play the selected video. That operation is fine the way it is and belongs in the Client as a request. What needs to be removed from the Client is the operation that populates the DataProvider.

Building a Factory Method for Populating and Returning a DataProvider: A Friend with Benefits

You might be asking yourself,

Is this really necessary? Why not just leave the DataProvider in the Client and populate it there?

The short answer is, of course not! It is not necessary, but you will find many benefits in doing so:

• Removes clutter from the Client
• Client can make request from external source
• Contents of DataProvider can be changed without breaking the rest of the program
• Other programs can use the same design pattern
• Adds flexibility for change and development

To get started, Figure 2 shows a chart diagram for this project dealing with a single concrete product—data for a series of videos.

Figure 2: Factory Method for a single set of data

In this case, the List object is in the Client class, but because it is the only object in the class that uses the data generated in the Factory Method design pattern, it is listed.

First, the Creator class provides the interface for all concrete creators. Most importantly is the factory method to be used in creating and delivering the DataProvider to the Client for use in the List component.

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

package
{
	//Abstract class
	//Creator
	import fl.data.DataProvider;
	import flash.errors.IllegalOperationError;
 
	public class Creator
	{
		private var dataNow:DataProvider;
 
		public function selectData():DataProvider
		{
			dataNow = createData();
			return dataNow;
		}
 
		// ABSTRACT Method (must be overridden in a subclass)
		protected function createData():DataProvider
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
			return null;
		}
	}
}

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

package
{
	//Concrete Creator (Factory)
	import fl.data.DataProvider;
	import flash.errors.IllegalOperationError;
 
	public class ConcreteCreatorPrague extends Creator
	{
		private var ds:DataSupply;
 
		override protected function createData():DataProvider
		{
			ds=new Prague();
			return (ds.deliverData());
 
		}
	}
}

1
2
3
4
5
6
7
8
9
10

package
{
	import fl.data.DataProvider;
 
	//Product
	interface DataSupply
	{
		function deliverData():DataProvider;
	}
}

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

package
{
	import fl.data.DataProvider;
 
	public class Prague implements DataSupply
	{
		public function deliverData():DataProvider
		{
			var prague:DataProvider=new DataProvider();
			prague.addItem( { label: "Panorama", data:"mp4:praguevid/panorama.f4v" } );
			prague.addItem( { label: "Charles Bridge", data:"mp4:praguevid/charlesbridge.f4v" } );
			prague.addItem( { label: "Old & New Town", data:"mp4:praguevid/newtown.f4v" } );
			prague.addItem( { label: "Mucha Glass", data:"mp4:praguevid/mucha.f4v" } );
			return prague;
		}
	}
}

Finally, all that the Client needs is to request the data it needs. Because, only a single concrete product has been created, this is simply a matter of creating List and DataProvider instances. Then to populate the DataProvider with data, the Client requests the data by instantiating the desired concrete creator through the Creator interface (abstract class). The following listing shows the operations in the process:

1
2
3
4
5
6
7

var create:Creator=new ConcreteCreatorPrague();
var prague: DataProvider=new DataProvider();
 
prague=create.selectData();
 
var list:List=new List();
list.dataProvider = prague;

Under any circumstances you need to create a DataProvider instance, a List instance and assign a DataProvider object to the List object. Using the Factory Method pattern, the only line of code required to request the contents for the DataProvider is the following:

   prague=create.selectData();

You can have hundreds of elements in the DataProvider, but using the suggested pattern, you still just need a single line in the Client to access it.

Expanding The Concrete Products Shows the Benefits

After going through the process we have, you may be thinking, What benefits?. After all, the DataProvider class itself is a pretty handy class in its own right. Why complicate things?

For a single data source, it is a bit hefty, but when you look at a larger picture, you can see that this Factory Method program can be used as a reliable mechanism to add more data sources. Figure 3 shows an expanded version of the original pattern:

Figure 3: Factory Method for expanded set of data

Before you get started on this new set of classes, you might want to download the files here. The Product interface (DataSupply) is the same as the original. However, because the concrete creator has more than a single option from the concrete products now, we’ll have to add a parameter to the factory method for choosing the concrete product we want. However, as you can see in the following program, there’s not much that is changed from the original Creator 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

package
{
	//Abstract class
	//Creator
	import fl.data.DataProvider;
	import flash.errors.IllegalOperationError;
 
	public class Creator
	{
		private var dataNow:DataProvider;
 
		public function selectData(dataSource:String):DataProvider
		{
			dataNow = createData(dataSource);
			return dataNow;
		}
 
		// ABSTRACT Method (must be overridden in a subclass)
		protected function createData(dataSource:String):DataProvider
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
			return null;
		}
	}
}

The concrete creator needs to be changed as well, both to add the new parameter and to set up a way to choose among the concrete products. It has been renamed, ConcreteCreatorVid to reflect that it is used in dealing with data that is used with the video player:

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

package
{
	//Factory
	import fl.data.DataProvider;
	import flash.errors.IllegalOperationError;
 
	public class ConcreteCreatorVid extends Creator
	{
		private var ds:DataSupply;
		override protected function createData(dataSource:String):DataProvider
		{
			switch (dataSource)
			{
				case "prague" :
					ds=new Prague();
					return(ds.deliverData());
					break;
				case "graduation" :
					ds=new Graduation();
					return(ds.deliverData());
					break;
				case "bloomfield" :
					ds=new Bloomfield ();
					return(ds.deliverData());
					break;
				default :
					throw new Error("Invalid video set specified");
					return null;
			}
		}
	}
}

Notice that the ConcreteCreatorVid holds a reference to the product interface (DataSupply) and then instantiates the concrete products (Prague, Graduation, Bloomfield) using an object typed as an interface. The Prague concrete product class does not change; so all that’s left is to create concrete product classes for the Graduation and Bloomfield video projects.

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

//Data for Graduation Project
package
{
	import fl.data.DataProvider;
 
	public class Graduation implements DataSupply
	{
		public function deliverData():DataProvider
		{
			var graduation:DataProvider=new DataProvider();
			graduation.addItem( { label: "Gathering", data:"mp4:graduationvid/gathering.f4v" } );
			graduation.addItem( { label: "Walking", data:"mp4:graduationvid/walk.f4v" } );
			graduation.addItem( { label: "Awarding Degrees", data:"mp4:graduationvid/degree.f4v" } );
			return graduation;
		}
	}
}
 
//Data for Bloomfield project
package
{
	import fl.data.DataProvider;
 
	public class Bloomfield implements DataSupply
	{
		public function deliverData():DataProvider
		{
			var bloomfield:DataProvider=new DataProvider();
			bloomfield.addItem( { label: "Introduction", data:"mp4:bloomfieldvid/intro.f4v" } );
			bloomfield.addItem( { label: "My Street", data:"mp4:bloomfieldvid/shadywalk.f4v" } );
			bloomfield.addItem( { label: "History", data:"mp4:bloomfieldvid/park.f4v" } );
			bloomfield.addItem( { label: "People", data:"mp4:bloomfieldvid/people.f4v" } );
			return bloomfield;
		}
	}
}

At this point you have all of the Factory Method classes. So now (finally!) we can look at a Client class that makes requests. Keep in mind that this is only one of two design patterns that this project is using. (In the next installment, we’ll refactor the a non-OOP video player into a State design pattern and incorporate this data-generating Factory Method design pattern.)

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

package
{
	import flash.display.Sprite;
	import fl.events.ListEvent;
	import flash.events.MouseEvent;
	import fl.controls.Button;
	import fl.controls.List;
	import fl.data.DataProvider;
 
	public class Client extends Sprite
	{
		private var btnPrague:Button=new Button();
		private var btnGrad:Button=new Button();
		private var btnBloom:Button=new Button();
		private var list:List=new List();
		private var create:Creator=new ConcreteCreatorVid();
 
		public function Client()
		{
			setUI();
			btnPrague.addEventListener(MouseEvent.CLICK,getPrague);
			btnGrad.addEventListener(MouseEvent.CLICK,getGraduation);
			btnBloom.addEventListener(MouseEvent.CLICK,getBloomfield);
		}
 
		private function setUI():void
		{
			btnPrague.x = 35,btnPrague.y = 160;
			btnPrague.label = "Prague";
			btnPrague.textField.background = true;
			btnPrague.textField.backgroundColor = 0xA19580;
			addChild(btnPrague);
			btnGrad.x = 35,btnGrad.y = 190;
			btnGrad.label = "Graduation";
			btnGrad.textField.background = true;
			btnGrad.textField.backgroundColor = 0xA19580;
			addChild(btnGrad);
			btnBloom.x = 35,btnBloom.y = 220;
			btnBloom.label = "Bloomfield";
			btnBloom.textField.background = true;
			btnBloom.textField.backgroundColor = 0xA19580;
			addChild(btnBloom);
			list.x = 35,list.y = 50;
			addChild(list);
		}
 
		private function getPrague(e:MouseEvent):void
		{
			var prague:DataProvider=new DataProvider();
			prague = create.selectData("prague");
			list.dataProvider = prague;
		}
 
		private function getGraduation(e:MouseEvent):void
		{
			var graduation:DataProvider=new DataProvider();
			graduation = create.selectData("graduation");
			list.dataProvider = graduation;
		}
 
		private function getBloomfield(e:MouseEvent):void
		{
			var bloomfield:DataProvider=new DataProvider();
			bloomfield = create.selectData("bloomfield");
			list.dataProvider = bloomfield;
		}
	}
}

As you can see, each button calls a function to load the List instance with a different set of data loaded into the DataProvider object. It’s just like the first version of the pattern except that a parameter has been added to select from among three data sets. Figure 4 shows the different outcomes in the List component:

Figure 4: Selected List object data

Both in our book and on this blog, you’ve seen other examples of the Factory Method design pattern; so this may not be new as far as a design pattern is concerned. However, it does show a different use of the pattern and how flexible it is. In the next installment, we’ll see how this pattern that provides UI data can be integrated with a State design to develop a video player that is set up so that adding more controls is quite simple.

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.

Looking at the principle in this new light, we can see how it works with a simple example. Suppose you’re doing a lot of work with Shape class objects. Right away you need circles and rectangles, but you might need other shapes later. So to get started, you set up your classes that you know you’ll need, but you want to leave the door open for easy extension. To get started you create an abstract class that leaves an abstract method to add different shape types. The following script is your initial starting point:

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

package
{
	import flash.display.Shape;
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	//Asbstract class do not instantiate
	public class IOpenClosed extends Sprite
	{
		protected var shape:Shape=new Shape();
 
		protected function makeShape(rw:Number,h:Number,c:Number):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		public function setShape(fillCol:uint,borderCol:uint,lw:Number,rw:Number,h:Number,c:Number):void
		{
			shape.graphics.beginFill(fillCol);
			shape.graphics.lineStyle(lw,borderCol);
			makeShape(rw,h,c);
			shape.graphics.endFill();
			addChild(shape);
		}
	}
}

You will notice that the makeShape() function in the setShape() method only has three parameters. That’s because the first two parameters are the x and y positions. These will be set to 0 using a literal. The stage position is placed using an instance of the shape.

Next, two little classes extend the abstract class to make the circle and rectangle. First the circle-making class extends the abstract class and then overrides the makeShape() function to add the graphics method for creating a circle .

1
2
3
4
5
6
7
8
9
10

package
{
	public class OCround extends IOpenClosed
	{
		override protected function makeShape(rw:Number,h:Number,c:Number):void
		{
			shape.graphics.drawCircle(0, 0, rw);
		}
	}
}

Next, we do the same thing for a rectangle.

1
2
3
4
5
6
7
8
9
10

package
{
	public class OCrectangle extends IOpenClosed
	{
		override protected function makeShape(rw:Number,h:Number,c:Number):void
		{
			shape.graphics.drawRect(0, 0, rw, h);
		}
	}
}

Okay, we’re all done. We’ll create a Client class to test it:

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

package
{
	import flash.display.Sprite;
	//Parameters for setShape are:
	//setShape(fillCol:uint,borderCol:uint,lw:Number,rw:Number,h:Number,c:Number):void
 
	public class Client extends Sprite
	{
		private var rec:IOpenClosed=new OCrectangle();
		private var cir:IOpenClosed=new OCround();
		private var rndrec:IOpenClosed=new OCroundrec();
 
		public function Client()
		{
			rec.setShape(0xC03000,0x32331D,4,100,60,0)
			rec.x=50, rec.y=50;
			addChild(rec);
 
			cir.setShape(0x787746,0x40411E,4,50,0,0)
			cir.x=100, cir.y=200;
			addChild(cir);
		}
	}
}

When tested, we can see that we get our shapes as shown in Figure 1.

Figure 1: Two shapes created with common interface

Obviously not rocket science, but it’s a handy tool for setting up different kinds of shapes.

What about Rounded Rectangles?

This part is the important part as far as both the Open/Closed principle and design patterns are concerned. Suppose you decide you need a rounded rectangle. With the Open/Closed principle in mind, you cannot modify the code but you can add to it through extension. So, let’s add a rounded rectangle:

1
2
3
4
5
6
7
8
9
10

package
{
	public class OCroundrec extends IOpenClosed
	{
		override protected function makeShape(rw:Number,h:Number,c:Number):void
		{
			shape.graphics.drawRoundRect(0, 0, rw,h,c);
		}
	}
}

That wasn’t hard. Add the following lines to the Client, and let’s test it:

1
2
3
4
5

private var rndrec:IOpenClosed=new OCroundrec();
….
rndrec.setShape(0x32331D,0xC03000,4,100,60,24)
rndrec.x=200, rndrec.y=50;
addChild(rndrec);

Figure 2 shows that a rounded rectangle has joined the circle and the rectangle on the stage:

Figure 2: A third shape is created through extension.

As you can see, while it was more work to set it up initially, it’s a lot less work to create new shapes. Also, requesting the shapes in the clients is very simple as well.

Into the Lunch Bucket

Here’s a handy and simple principle that you can see reflected in many different design patterns. For example, the Decorator, Composite, and Builder offer change through extension. So, to add this principle to your lunch bucket, add a class that creates ellipses. If you can do that, you can both understand the principle and apply it. That means it’s ready for work. Figure 3 shows the missing ellipse:

Figure 3: Test your understanding by adding an ellipse to the mix.

One caveat to using this principle is one of the first design pattern principles: favor composition over inheritance. That doesn’t mean you cannot create new elements for your program using extension—clearly some design patterns do so. Rather, just keep in mind that the principles in both OOP and design patterns work in conjunction with one another and you need to realize that not all OOP solutions are grounded in a single principle.

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.