Removing Decorations can be Tricky

The 2010 film, “Repo Men” is about a dark future where body parts are purchased much like homes. You get the needed part (like Steve Jobs got his liver) and pay for it with a mortgage. If you fall behind in your payments, the Repo Men come and take it away so that it can be sold to another customer. It turns out that removing a decorator from a component in the Decorator Design Pattern is about as draconian. All along I had imagined it about as simple as removing ornaments from a Christmas tree. Apparently others have issued similar claims, but try and find a decent example, and you’re likely to come up blank. I finally was able to track down an example in O’Reilly Media’s Head First Labs, and it works; sort of. First, though, consider why adding and removing decorations is worthwhile investigating.

Why Removing Concrete Decorations is Important

Now that I’ve been programming madly to get ActionScript 3.0 to work with mobile devices (the iPhone in particular), I’m finding that creating graphic objects is sloooow. The idea behind developing games with patterns like Decorator is that I can take a component and add and remove decorations without having to recreate the object with all of elements that go with it. I can just add and subtract concrete decorators and leave the component as is. This would seem much faster because I’m instantiating less. (Yes, the Flyweight pattern would be another for adding some speed to the process.) Of course you don’t have to be developing for mobile devices; it’s just as handy for computers.

Removing One Decoration Works Fine

I tried out the fix suggested in Head First Labs, and it works dandy. Go ahead and download all the files (they’re two sets in a single zip file; one for removing a single decorator and another for multiple) and then click the Play button to see how a single removal works:

All downloads are now on the University of Hartford’s MWDD Download Page. Select the last window to the right (ActionScript 3.0/Flash) and click on the bottom link and then click the Download button.

donE
The movement to the left and right was to show how the decorated component is a “single object,” but even that is a bit of fakery. Here’s the code:

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

package
{
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	//Abstract class. Do not instantiate directly
	//Extend the class for concrete child classes
 
	public class Component;
	{
		protected var armor:Sprite;
 
		public function getarmor():Sprite
		{
			return armor;
		}
		//remove
		public function removeArmor():Component
		{
			return this;
		}
	}
}

In the Component abstract class, you can see the addition of a single added method, removeArmor(). What you may be scratching your head about is why a Component object is returned. That’s what’s decorated, no? Shouldn’t it be zapping a decoration? What the function appears to be doing is stripping the component of all decorations. But let’s move on to the Decorator, both abstract and concrete:

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

//Abstract Class Decorator
package
{
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	//Abstract class. Do not instantiate directly
	//Extend the class for concrete child classes
 
	public class Decorator extends Component
	{
		override public function getarmor():Sprite
		{
			return armor;
		}
		protected var char:Component;
	}
}
 
//Concrete Decorator Class
package
{
	import flash.display.Sprite;
	//Concrete decorator Shield
 
	public class DecShield extends Decorator
	{
		public function DecShield(char:Component)
		{
			this.char = char;
		}
		//Shield is a Sprite class
		public override function getarmor():Sprite
		{
			armor=new Shield();
			armor.x=75,armor.y=250;
			return armor;
		}
		//remove Shield
		override public function removeArmor():Component
		{
			return char;
		}
	}
}

The char variable is a protected Component one inherited from the Decorator abstract class. What is “removed” is any decoration, and in this case, it’s the last decoration. In other words, it just returns the “naked” concrete component.

The base component is in the concrete component, Warrior. It’s just a Sprite stored in the library. (StickMan())

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

//Concrete component
package
{
	import flash.display.Sprite;
 
	//Concrete component
	public class Warrior extends Component
	{
		private var warrior:Sprite=new StickMan();
		public function Warrior()
		{
			armor=warrior;
		}
	}
}

So, the trick in this implementation of decoration removal is simply to return a component with no decorations; hence, ‘remove’ the decoration.

The Client class takes care of everything by first adding a graphic component, and then providing a single decoration and then removing that decoration.

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

package
{
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	//Client class
	public class Client extends Sprite
	{
		private var warrior:Component=new Warrior();
		private var addBtn:Button=new Button();
		private var removeBtn:Button=new Button();
		private var moveBtn:Button=new Button();
		private var moveLBtn:Button=new Button();
		private var warriorSpirit:Sprite=new Sprite();
		private var warriorObj:Sprite;
		private var shieldObj:Sprite;
 
		public function Client()
		{
			warriorObj = warrior.getarmor();
			addChild(warriorSpirit);
			warriorSpirit.addChild(warriorObj);
			addBtn.x = 250,addBtn.y = 100;
			addBtn.label = "Add Shield";
			addBtn.addEventListener(MouseEvent.CLICK,addShield);
			removeBtn.x = 250,removeBtn.y = 140;
			removeBtn.label = "Remove Shield";
			removeBtn.addEventListener(MouseEvent.CLICK,removeShield);
			addChild(addBtn);
			addChild(removeBtn);
 
			moveBtn.label = "Move Right";
			moveBtn.addEventListener(MouseEvent.CLICK,moveRight);
			moveBtn.x = 250,moveBtn.y = 180;
			addChild(moveBtn);
 
			moveLBtn.label = "Move Left";
			moveLBtn.addEventListener(MouseEvent.CLICK,moveLeft);
			moveLBtn.x = 360,moveLBtn.y = 180;
			addChild(moveLBtn);
		}
 
		private function addShield(e:MouseEvent):void
		{
			warrior = new DecShield(warrior);
			shieldObj = warrior.getarmor();
			warriorSpirit.addChild(shieldObj);
		}
 
		private function removeShield(e:MouseEvent):void
		{
			warrior = warrior.removeArmor();
			warriorSpirit.removeChild(shieldObj);
			warriorSpirit.addChild(warrior.getarmor());
		}
 
		private function moveRight(e:MouseEvent):void
		{
			warriorSpirit.x +=  30;
		}
 
		private function moveLeft(e:MouseEvent):void
		{
			warriorSpirit.x -=  30;
		}
 
	}
}

You will also notice that the buttons that moved the objects to the left and right did so within a single sprite (warriorSpirit) where both the component and its decoration were placed as returned Sprite objects. While the decoration is composed in the pattern, it and the concrete component are in no way “locked” together as sprites. In order for them to be locked, they had to be placed in a wrapper sprite which was moved across the stage.

Adding more than a single decoration does not do well with removal

In making a game, you want to be able to add or remove decorations at will. You should be able to remove one, two or all without a problem. However, using the only decoration removal method I could find, I was unable to do so. When you try out the following implementation, here’s what happens: If you add one decoration and then remove it, everything works fine. However, if you add more than a single decoration before removing it, only the last one added will be removed. What appears to happen is that when the remove() method fires, it returns an undecorated component. The current one is replaced, but the previous decoration stays put as an independent entity. That’s why with only one decoration, everything seems to work ok.

Click the Play button to see what happens:

The only added class is a DecSword concrete decorator class to call up the Sword class and position it on 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

package
{
	import flash.display.Sprite;
	//Concrete decorator Sword
 
	public class DecSword extends Decorator
	{
		public function DecSword(char:Component)
		{
			this.char = char;
		}
		//Shield is a Sprite class
		public override function getarmor():Sprite
		{
			armor=new Sword();
			armor.x=90, armor.y=180;
			armor.rotation=20;
			return armor;
		}
		//remove Sword
		override public function removeArmor():Component
		{
			return char;
		}
	}
}

It’s identical to DecShield except for the different position instantiates the Sword sprite instead of the Shield.

In addition to adding a sword decoration, it also changes the way that the sprites are placed on the stage in the Client class. It does not have the spriteWarrior sprite to acts as a holder for all of the decorations added to the stage. Instead, the concrete component and decoration sprites are placed directly on 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

package
{
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	//Client class
	public class Client extends Sprite
	{
		private var warrior:Component=new Warrior();
		private var addBtn:Button=new Button();
		private var removeBtn:Button=new Button();
		private var addSwBtn:Button=new Button();
		private var removeSwBtn:Button=new Button();
		private var warriorObj:Sprite;
		private var shieldObj:Sprite;
		private var swordObj:Sprite;
 
		public function Client()
		{
			warriorObj=warrior.getarmor();
			addChild(warriorObj);
 
			addBtn.x=250,addBtn.y=100;
			addBtn.label="Add Shield";
			addBtn.addEventListener(MouseEvent.CLICK,addShield);
			addChild(addBtn);
 
			removeBtn.x=250,removeBtn.y=140;
			removeBtn.label="Remove Shield";
			removeBtn.addEventListener(MouseEvent.CLICK,removeShield);
			addChild(removeBtn);
 
			addSwBtn.x=360,addSwBtn.y=100;
			addSwBtn.label="Add Sword";
			addSwBtn.addEventListener(MouseEvent.CLICK,addSword);
			addChild(addSwBtn);
 
			removeSwBtn.x=360,removeSwBtn.y=140;
			removeSwBtn.label="Remove Sword";
			removeSwBtn.addEventListener(MouseEvent.CLICK,removeSword);
			addChild(removeSwBtn);
		}
 
		private function addShield(e:MouseEvent):void
		{
			warrior=new DecShield(warrior);
			shieldObj=warrior.getarmor();
			addChild(shieldObj);
		}
 
		private function removeShield(e:MouseEvent):void
		{
			warrior = warrior.removeArmor();
			removeChild(shieldObj);
			addChild(warrior.getarmor());
		}
 
		private function addSword(e:MouseEvent):void
		{
			warrior=new DecSword(warrior);
			swordObj=warrior.getarmor();
			addChild(swordObj);
		}
 
		private function removeSword(e:MouseEvent):void
		{
			warrior = warrior.removeArmor();
			removeChild(swordObj);
			addChild(warrior.getarmor());
		}
	}
}

By using removeChild(obj), it would be possible to remove the sprite objects of the shield and sword from the stage, but I do not believe it would remove them as a decoration from the component. Currently, the removeChild() function targets whichever sprite-object-as-decorator was the last created decoration.

Be The Repo Man!

I’ve been butting my head against this issue for a while, and I have a feeling that either I’m missing something quite obvious or I’m very close to a solution that still eludes me. So here’s a chance for you, the reader, to work out a way to retrieve the decorations from the component in any order. So be the Repo Man (or Woman) and see if you can work out a solution.

Change orientation with device position

Reminder: We’ve placed all of the downloads on the University of Hartford’s Multimedia Web Design and Development download page. Just select the bottom on the ActionScript 3.0 files and click the download button.

Flash Builder Tip: First create an ActionScript Project so that you can test it as you develop. Once you have it all developed, create an ActionScript Mobile Project and just copy and paste the files from the AS Project.

Re-Decorating

In this first part all I want to do with this mobile game is to build and decorate the warrior and put it on an iOS mobile device using Flash Builder. The mechanics are very similar to previous posts on using the Decorator pattern to arm a character (See here and here.) Figure 1 shows a file diagram of the Decorator implementation:

Figure 1:Decorator File Diagram

Since this thing is going to be in pure code, we need to create a “warrior” in code, which was not done in the previous posts linked above. So outside of the pattern, we need a graphic image, as provided 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
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

package
{
	import flash.display.Shape;
	import flash.display.Sprite;
 
	public class BuildWarrior extends Sprite
	{
		private var head:Shape=new Shape();
		private var torso:Shape=new Shape();
		private var lftArm:Shape=new Shape();
		private var rtArm:Shape=new Shape();
		private var lftLeg:Shape=new Shape();
		private var rtLeg:Shape=new Shape();
 
		public function assemble():Sprite
		{
			this.addChild(makeHead());
			this.addChild(makeTorso());
			this.addChild(makeLftArm());
			this.addChild(makeRtArm());
			this.addChild(makeLftLeg());
			this.addChild(makeRtLeg());
			return this;
		}
 
		private function makeHead():Shape
		{
			head.graphics.lineStyle(1,0x6F74B3);
			head.graphics.beginFill(0x6F91A6,.50);
			head.graphics.drawRect(30,17,10,3);
 
			head.graphics.lineStyle(0.25,0x0066ff);
			head.graphics.beginFill(0x035AA6,.40);
			head.graphics.drawCircle(35, 7,10);
			head.graphics.lineStyle(1,0x6F74B3);
			head.graphics.moveTo(30,6);
			head.graphics.lineTo(34,6);
			head.graphics.moveTo(36,6);
			head.graphics.lineTo(40,6);
			head.graphics.moveTo(32,12);
			head.graphics.lineTo(38,12);
			graphics.endFill();
			return head;
		}
 
		private function makeTorso():Shape
		{
			torso.graphics.lineStyle(1,0x6F74B3);
			torso.graphics.beginFill(0x6F91A6,.50);
			torso.graphics.drawTriangles(Vector.<number>([10,20, 60,20, 35,90]));
			torso.graphics.endFill();
			return torso;
		}
 
		private function makeLftArm():Shape
		{
			lftArm.graphics.lineStyle(1,0x6F74B3);
			lftArm.graphics.beginFill(0x6FB3A7,.75);
			lftArm.graphics.drawRect(10,20,10,40);
			lftArm.graphics.drawRect(10,60,40,8);
			lftArm.graphics.endFill();
			return lftArm;
		}
 
		private function makeRtArm():Shape
		{
			rtArm.graphics.lineStyle(1,0x6F74B3);
			rtArm.graphics.beginFill(0x6FB3A7,.75);
			rtArm.graphics.drawRect(50,20,10,40);
			rtArm.graphics.drawRect(51,60,8,40);
			rtArm.graphics.endFill();
			return rtArm;
		}
 
		private function makeLftLeg():Shape
		{
			lftLeg.graphics.lineStyle(1,0x6F74B3);
			lftLeg.graphics.beginFill(0x6FB3A7);
			lftLeg.graphics.drawRect(23,70,12,45);
			lftLeg.graphics.drawRect(24,115,10,45);
			lftLeg.graphics.endFill();
			return lftLeg;
		}
 
		private function makeRtLeg():Shape
		{
			rtLeg.graphics.lineStyle(1,0x6F74B3);
			rtLeg.graphics.beginFill(0x6FB3A7);
			rtLeg.graphics.drawRect(36,70,12,45);
			rtLeg.graphics.drawRect(37,115,10,45);
			rtLeg.graphics.endFill();
			return rtLeg;
		}
	}
}

All of the concrete decorators similarly implement coded graphic representations. Of course, all of these are “outside” of the design pattern but are useful to see in the contact of the pattern.

The Client

In the actual mobile client, you begin with a super(); call and support for auto orientation in the iOS device. The code is automatically generated:

1
2
3

// support autoOrients
stage.align = StageAlign.TOP_LEFT;
stage.scaleMode = StageScaleMode.NO_SCALE;

I tossed out the super(); call, and generated the following 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

package
{
	import flash.display.Sprite;
	import flash.display.StageAlign;
	import flash.display.StageScaleMode;
 
	public class MobileDecState extends Sprite
	{
		private var warrior:Component=new Warrior();
		private var warriorSpirit:Sprite=new Sprite();
		public function MobileDecState()
		{
			warriorSpirit.addChild(warrior.getarmor());
			warriorSpirit.x=50,warriorSpirit.y=50;
			addChild(warriorSpirit);
 
			warrior=new DecBodyArmor(warrior);
			warriorSpirit.addChild(warrior.getarmor());
 
			warrior=new DecShield(warrior);
			warriorSpirit.addChild(warrior.getarmor());
 
			warrior=new DecHelmet(warrior);
			warriorSpirit.addChild(warrior.getarmor());
 
			warrior=new DecParticleCompressor(warrior);
			warriorSpirit.addChild(warrior.getarmor());
 
			// support autoOrients
			stage.align = StageAlign.TOP_LEFT;
			stage.scaleMode = StageScaleMode.NO_SCALE;
		}
	}
}

Publishing for Mobile

For some reason, more steps are involved in publishing for Flash Builder than Flash Pro. However, once you have your certificate (it has a .p12 extension) and your provisioning file created using the tools available to Apple developers; it’s pretty simple. If you don’t know about the Apple iOS developer program for both Windows and Mac users, you need to go there first.

Here’s how to publish using Flash Builder: (Download the Beta version/update of Flash Builder 4.5.1. While you’re at it, download the beta version of Adobe AIR 3.)

1. Open a New > New ActionScript Mobile Project (Figure 2)

Figure 2: Open a New ActionScript Mobile Project

2. Specify your target platform as Apple iOS with Automatically reorient selected and click Next. (Figure 3)

Figure3: Mobile Settings

3. Click the Platform Setting and select Platform and Target devices (Figure 4)

Figure 4: Specify Platformsettings

4. Build Paths provides the opportunity to add SWC folders or a project. Figure 5 shows using the default settings.

Figure 5: Include additional or different paths if requires

5. The next step in creating your app will not come until you are finished coding it all. Then when you press the green arrow (Run) button at the top, you will begin the Run Configurations sequence. Figure 6 shows the On device radio button selected. You are likely to see some red circles with white ‘X’s in them, but don’t worry. If there’s one next to the Packaging setting click the [Configure] link.

Figure 6: Run Configurations

6. Set the Certificate and Provisioning file. Both of these should be ready using the software that the Apple iOS Developer program provides. Use the Browse buttons to locate yours. (These cannot be generated using Adobe software.)

Figure 7: Setting Certificate and Provisioning files

Once the certificate and provisioning file are set, click the Apply button and then click OK.

7. If all has gone right you will see the Packaging Completed window shown in Figure 8. At this point you will have to open iTunes on your computer, and make sure that your mobile device is connected to your computer. You will need to locate the .ipa package and drop it into the iTunes library. It’s easiest to just click the (Reveal package in Finder) to get the .ipa package.

Figure 8: Completed Window

8. Figure 9 shows the bin-debug folder opened with the .ipa package. Be sure that the Apps window on your iTunes library is selected and drag the .ipa package into the iTunes library.

Figure 9 Drag .ipa package into iTunes Apps Library

9. The final step requires that you select the connected device (shown right above Little Richard Greatest Songs in Figure 10 ) and then find your new app in the Sync Apps window. Be sure to check the box next to the app. Then click the Apply button. Clicking the Apply button will then begin the Sync process. Once it is finished you should see the icon.

Figure 10: Adding the app to an iOS device

Adding the State Design

With this and the previous posts for mobile devices, you’ve seen that design patterns work well with mobile app development. All of the advantages found in design pattern development for computers can be found in creating applications for mobile devices.

In the next post, this process will be continued by adding a State pattern to the app to create a game. If you don’t have a mobile device, you can use the same coding for making the app for your computer.

Make Your Own Apps with Design Patterns

Having finally got my magical combination of permissions set up just so, the process began coming fairly easily. The problem is not Adobe, but rather getting the files from Apple just right. Once you get the files, you can use them over an over. One is a certificate file with a .p12 extension, and the other is a provisioning file. It looks like a lot of people are having the same problem because when I finally found a solution on the Web at StackOverflow several other developers indicated (with heart-felt thanks) that they were encountering the same problem. (The solution that worked for me was to start over and delete all provisioning profiles and login keychain.) So if you got your Apple iOS Developer ticket ($99 or free to University students/faculty), that’s just the first part. The next part is to hook up your iOS device (mine is a 3S iPhone) and using the Xcode development tools, go through a process that generates the files you need. The following image shows what these little gems look like. If you put those two files in with your AIR iOS files, it’s a piece of cake. (Go ahead and download the files as well.)

Same files can be used with different apps

Apple provides videos and a whole slew of tools and aids, and if you follow the instructions, you should be able to develop the right files. (Sad experience had led me to suggest that you take your time and follow instructions carefully.) Anyway, whether you get the certificate and provisioning files on the first time or whether you struggle like I did, once you’ve got them; they’re good for about four months. You can develop on either a Mac or Windows PC and re-use the same files on different apps. (I haven’t gone through the process that Apple has for getting an app in the App Store; so you’re on your own in that department.) The image on the right is a screenshot taken with an iPhone:

Animated tween, text and graphic

Step-By-Step

This section walks you through the process of working with a Flash Pro project set up for use with iOS. In the previous post on iOS, the sample project was to create banners that can be used in a Factory Method context by loading external .SWF files. On the iPhone, that didn’t work. The problem seemed to be the mobile device’s inability to grab the external .SWF files even though, the .SWF files were included in the General settings for the Included files window. So, using the same tweens, I created MovieClips and put them in the Flash Pro library and then set them up as classes. Then in the concrete product files, I just instantiated classes with the tweens instead of loading external .SWF files, and the rest of the program was unchanged. (That is where design patterns really shine—easy to make changes.)

Okay, now to step through the process. This was all done using AIR 3.0, Flash Player 11 public betas on a iMac running the new Lion OS. After you open a new AIR for iOS and write all of your code and add any graphics and text, the first step is to select the FLA file, make sure that nothing is selected on the stage and then click the little wrench icon next to the Player selection where it should indicate ‘AIR for iOS.’ That will open the AIR for iOS Settings window as shown in Figure 1:

Figure 1: General Settings of AIR for iOS

For getting started, choose Full screen instead of Auto orientation. Use the CPU for the Rendering processor, specify your device and choose the Standard resolution. The included files will be an .SWF and .XML file. Leave those alone, and for this app, you do not need to add any others.

For this next step, you’ll need both the certificate and provisioning files in the same folder with the other class files. So if you haven’t created those files and linked them to the device you’re testing it on; do so now. The click the Deployment button next to the General button at the top of the AIR for iOS Settings window. Figure 2 shows the deployment settings:

Figure 2: Deployment window

The password for the certificate is the one you entered when you created the certificate—not one associated with your computer. Use the search folder to find your Provisioning profile file. The App ID is the name you gave your initial FLA file—I’m in the habit of calling all of mine “Client,” but now I’ve got to think about what users will see on their mobile device..

This post does not get into the iOS deployment beyond the local development stage. So, select the “Quick publishing for device testing” or “Quick publishing for device debugging.” I selected the former because I chose to do the debugging using the standard Flash tools. After all I went through to get the certificate and mobile provision files to work right, I wasn’t about to tempt fate just yet and do more than the minimum.

This final step is fun. You can easily create your own iOS icon. Here’s what you need to do to get started:

1. Create a square image with your logo or some symbol you want to use to identify you application. Save it as a .PNG file. (In the image at the top of this post, you can see the two application icons using the Sandlight logo.) Be sure that the image has equal width and height.
2. Save three images in sizes 29 pixel square, 57 pixel square and 512 pixel square. Depending on the mobile device, you may want to create other sizes as well. I started off with the Adobe Illustrator version and saved each size as a PNG file.
3. Place the three image files in a folder named “icons” and place the icons folder in the directory where you are creating your mobile app.

In Figure 3, you can see the preview window showing the image used for the application described in this post.

Figure 3: Assigning icons for app image

Be sure to click each icon size for each of the three sizes and load the URL (icons/iconXX.png) before you click OK. Note also that two of the icons are settings for iPads, and so if you have an iPad, create image files for those as well.

Installing your iOS on your Mobile Device

Now you’re set to Publish your files required for an iOS mobile app. When you click “Publish” you will find that it takes a while to process everything. Once you’re finished, you will see all the files generated for your iOS device. Figure 4 shows the files you will see—including the all-important .IPA file.

Figure 4: Files used and generated

As you can see in Figure 4, one of the files is named BannerFactory.ipa. That is the file that will install your app onto your iOS mobile device. Connect your iPhone or iPad or iWhatever that runs on iOS, and double-click the IPA file and it will upload your app into the iTunes Apps folder. (On your iTunes, click Apps in the LIBRARY folder, and you should see your new application as shown in Figure 5.)

Figure 5: iTunes Apps folder

If you see your application icon and file, you’ve been successful—up to this point. The last step is to install your app onto your mobile device. The final step is to select your device and then check your application Sync. Figure 6 shows iTunes with your application selected (checkbox) and ready for Sync.

Figure 6: App set for installing in iPhone

Note in Figure 6 that the iOS device is selected under DEVICES in the left panel and that the new application (BannerFactory) has a check next to it. Click the Sync button (or Apply and then Sync) and if you have your device properly identified, you will see your icon and app on your mobile device.

Code your own Sprite classes

When I’m working on an example, I’ll use a combination of Flash Pro and Flash Builder. However, using Flash Pro, all of my drawings are in the Flash Library and may not be accessible to Flash Builder users. Besides, my drawings are pretty simple composed of basic shapes—rectangles, circles and triangles. These images are transformed into Sprite classes in the Symbol Editor of Flash Pro, and the type is changed from the default MovieClip to Sprite. If I coded the images as Sprites using ActionScript 3.0, the Flash Builder users would be able to more easily use them and the Flash Pro users could use them with equal ease.

Let’s face it, my graphics are not going to get any better whether I code them or draw them; so why not code them? So that’s what I’ve done. In the previous post on the Decorator design pattern for beginners, I had three graphic “armor” pieces that were used with concrete decorator classes. All I’ve done for this mini-post is to provide the “armor” sprites as pure code. From now on when I have a Sprite image, I’ll just code them up in ActionScript 3.0 as Sprite classes and make it easy for everyone. Here’s the Shield, BodyArmor and Helmet classes: (Next page.)

Shield

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.Shape;
 
	public class Shield extends Sprite
	{
		private var shield:Shape = new Shape();
		public function Shield()
		{
			shield.graphics.lineStyle(1,0x0066ff);
			shield.graphics.beginFill(0x0033ff,.50);
			shield.graphics.drawCircle(25, 30,31.25);
			graphics.endFill();
			addChild(shield);
		}
	}
}

Body Armor

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

package
{
	import flash.display.Sprite;
	import flash.display.Shape;
	public class BodyArmor extends Sprite
	{
		private var bodyArmor:Shape = new Shape();
		public function BodyArmor()
		{
			bodyArmor.graphics.lineStyle(1,0x990000);
			bodyArmor.graphics.beginFill(0x999999,.50);
			bodyArmor.graphics.drawTriangles(Vector.<number>([0,0, 116,0, 58,100]));
			bodyArmor.graphics.endFill();
			addChild(bodyArmor);
		}
	}
}

Helmet

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

package
{
	import flash.display.Sprite;
	import flash.display.Shape;
	public class Helmet extends Sprite
	{
		private var helmet:Shape = new Shape();
		public function Helmet()
		{
			helmet.graphics.beginFill(0xcc0000);
			helmet.graphics.moveTo(0, 25);
			helmet.graphics.curveTo(30, -20, 60, 25);
			helmet.graphics.endFill();
			helmet.graphics.lineStyle(2,0x996600);
			helmet.graphics.moveTo(2, 25);
			helmet.graphics.lineTo(2, 0);
			addChild(helmet);
		}
	}
}

I realize that this is pretty simple stuff, but if it helps beginners working with OOP and classes, not to mention design patterns, it’s worth it. Now, all that you have to do is to create the Warrior!!

Decorator Adds Changes without Changing the Object

In looking over the chapter on the Decorator pattern in our book I’ve felt that maybe I picked too complex a set of examples. In a Decorator example on this blog I attempted to remedy that with a very easy yet somewhat abstract example. However, I’ve decided to try and have a hugely simple example that is both interactive and solves a practical program in games. The knights of yore represent a good metaphor for the Decorator Design Pattern. The Component (knight) is decorated with armor. The same knight may have more than a single suit of armor and yet easily be recognized as the same knight. We could put him in a time machine and trade his steel suit of armor with one decorated with kevlar or some other modern weapon-stopping armor.

In a game context, different characters can be decorated with different weapons, armor and capabilities. If we have to provide our characters with a set of features at the outset, we can get stuck easily if we want to make changes to the character. The Decorator pattern recognizes that in dynamic situations, you need dynamic solutions. You don’t want to have to create a new character every time the character changes. With the Decorator, it’s easy to make changes without changing the core component (character). In this example, I used a graphic warrior and three different graphic semi-opaque graphic armor. To optimize the simplicity, each of the four elements—a component (character) and three types of armor (shield, breast plate and helmet) serve to illustrate the pattern. Further, I used a different class for each as well. These were stored in the library as Sprites. Use the Play and Download buttons below to become familiar with the pattern:

If you click the Play button, the initial figure is the “Concrete Component” participant, and as you click each button in turn, a new “Concrete Decorator” appears. (If you keep clicking the decorator buttons, the decorators accumulate. You can add a line of code to remove them easy enough, but I didn’t in an effort to keep it as simple as pie.)

The Classes

The class diagram and the whole pattern always leaves me with a question mark over my head like a befuddled cartoon character. However, after looking at the class diagram for a while, it begins to make sense. The unusual aspect of the pattern is that the abstract class Decorator subclasses the abstract class Component. In other words, one abstract class inherits from another. Further, the Decorator “wraps” the Component. Figure 1 shows the Decorator class diagram:

Figure 1: Decorator class diagram

The major feature of the design pattern is the curving reference (an aggregate relationship) from the Decorator to the Component. The inheritance of the ConcreteComponent is a straight inheritance from an abstract class. That’s pretty clear. However, the “wrapping” looks a bit different and one way to “see” it is through the Client. Assuming that the concrete object (the Warrior) is already there, the following code is involved in wrapping the component in a concrete decorator (a Shield, for example.) The code in the Client looks like the following:

1
2

conComponent = new DecShield(conComponent);
mover.addChild(conComponent.getarmor());

In this example you have the following:

• conComponent is typed as a Component
• conComponent instantiates a concrete decorator with itself as a parameter
• the conComponent instance invokes the getarmor() method, a Component method, that returns the armor’s image

The trick is that each of the concrete decorators inherits both the Component and Decorator interfaces. As a result, the armor (or anything else) is able to change the appearance of the component without changing the concrete component itself.

A Running Start

In looking at the code, I think that it may be helpful to begin with the Client that makes a request through the Component abstract class. It’s a little busy for a Client because it sets up a UI and allows users to add one concrete decorator at a time. Yet in all, it’s pretty simple:

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

package
{
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	public class Client extends Sprite
	{
		private var conComponent:Component=new Warrior();
		private var btnShield:Button=new Button();
		private var btnBodyArmor:Button=new Button();
		private var btnHelmet:Button=new Button();
		private var mover:Sprite=new Sprite();
		public function Client()
		{
			btnShield.addEventListener(MouseEvent.CLICK,addShield);
			btnShield.x = 10,btnShield.y = 40,btnShield.label = "Shield";
			addChild(btnShield);
 
			btnBodyArmor.addEventListener(MouseEvent.CLICK,addBodyArmor);
			btnBodyArmor.x = 10,btnBodyArmor.y = 65,btnBodyArmor.label = "Body Armor";
			addChild(btnBodyArmor);
 
			btnHelmet.addEventListener(MouseEvent.CLICK,addHelmet);
			btnHelmet.x = 10,btnHelmet.y = 90,btnHelmet.label = "Helmet";
			addChild(btnHelmet);
 
			mover.addChild(conComponent.getarmor());
			mover.x = 100,mover.y = 100;
			addChild(mover);
		}
 
		private function addShield(e:MouseEvent):void
		{
			conComponent = new DecShield(conComponent);
			mover.addChild(conComponent.getarmor());
		}
 
		private function addBodyArmor(e:MouseEvent):void
		{
			conComponent = new DecBodyArmor(conComponent);
			mover.addChild(conComponent.getarmor());
		}
 
		private function addHelmet(e:MouseEvent):void
		{
			conComponent = new DecHelmet(conComponent);
			mover.addChild(conComponent.getarmor());
		}
	}
}

Automatically places the Warrior (concrete component) on the screen and lets the user add decorators one at a time. In studying the unusual way in which requests are made for each decorator, we will now back up into the abstract Component and Decorator classes.

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

//Component
package
{
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	//Abstract class. Do not instantiate directly
	//Extend the class for concrete child classes
 
	public class Component
	{
		protected var armor:Sprite;
 
		public function getarmor():Sprite
		{
			return armor;
		}
	}
}

In this particular case, the abstract class isn’t very abstract. The single method sets up the component interface, as either a concrete component or a concrete decorator to be sent back as a Sprite instance. The details of the getarmor() method are specified in the concrete decorators.

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

package
{
	import flash.errors.IllegalOperationError;
 
	//Abstract class. Do not instantiate directly
	//Extend the class for concrete child classes
 
	public class Decorator extends Component
	{
		protected var char:Component;
	}
}

The Decorator, which extends the Component, is made up of a single property that is typed as a Component. However, the property is used as a reference to the object decorated and not a change in the concrete component itself.

The Concrete Classes

The concrete classes are ones that provide an image on the screen. All of them were created in the Flash Pro library, but they could have been done by creating sprites classes with Flash Builder. (In a mini-post later on this week, there’ll be an example of how to use Flash Builder to create graphic Sprites equivalent to those done in Flash Pro.)

The concrete component has only a single component that will be decorated with the concrete decorators. In this case, the concrete component class is named “Warrior.” It provides a warrior to dress with armor.

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

//Concrete Component
package
{
	//Concrete component
	public class Warrior extends Component
	{
		//Delphi is a Sprite class
		public function Warrior()
		{
			armor=new Delphi();
		}
	}
}

The Warrior uses an instance of the Delphi class that is nothing more than a graphic depiction of the warrior to be decorated. (By the way, “Delphi” is a conjunction of the Greek letters Delta Phi or DP or Design Patterns!)

The concrete decorators are all tied into the concrete component through the wrapping of the component. Each of the concrete decorators extends the Decorator. However, since the Decorator extends the Component, each of the concrete component also inherit the Components methods and properties. Because the Component class is abstract (in the way it is treated), each method must be overridden. In this way, unique elements can make up the different concrete decorations. However, to keep everything as simple as possible, the Sprite classes are just ones in the Library.

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

//Shield
package
{
	import flash.display.Sprite;
	//Concrete decorator Shield
 
	public class DecShield extends Decorator
	{
		public function DecShield(char:Component)
		{
			this.char=char;
		}
		//Shield is a Sprite class
		public override function getarmor():Sprite
		{
			armor=new Shield();
			armor.x=100,armor.y=100;
			return armor;
		}
	}
}
//Body Armor
package
{
	import flash.display.Sprite;
	//Concrete decorator Body Armor
 
	public class DecBodyArmor extends Decorator
	{
		public function DecBodyArmor(char:Component)
		{
			this.char=char;
		}
		//BodyArmor is a Sprite class
		public override function getarmor():Sprite
		{
			armor=new BodyArmor();
			armor.x=12,armor.y=57;
			return armor;
		}
	}
}
 
//Helmet
package
{
	import flash.display.Sprite;
	//Concrete decorator Helmet
 
	public class DecHelmet extends Decorator
	{
		public function DecHelmet(char:Component)
		{
			this.char=char;
		}
		//Helmet is a Sprite class
		public override function getarmor():Sprite
		{
			armor=new Helmet();
			armor.x=39,armor.y=-9;
			return armor;
		}
	}
}

Adding Armor

Let me make a couple of suggestions. First, add a weapon or two or more armor. This will entail creating a new concrete decorator. You can make the armor or weapon as simple or complex as you like. If you’re using Flash Builder, just create a Sprite class with graphics that depict a weapon. (By the way, later this week, I want to do a short post on creating your own image class library if you’re using Flash Builder. (This is just for beginners; so it will be simple.) Anyway, if you play with it, you’ll come away understanding it far more than just looking at what I’ve done. Besides it’s fun and we’d really like to see some of your ideas.

In our book, the most real world practical example was a car dealership where different models of hybrid cars (Components) were set up with different accessories (Decorators) to arrive at a final price. As different models of hybrids became available, they could be added to the components and as different accessories came and went, they could be added to the program without having to disrupt the structure of the program. The pricing of the car was based on both on the base price (Component) and the whistles and bells (Decorators) the buyer selected. Once set up, the site is easy to maintain, update and reuse in a different context.

In this post we want to provide a simple yet usable example that can be modified for your own needs. Many of the simple examples we’ve seen (or created ourselves) have made extensive use of string and numeric variables and/or trace output. Given the fact that practical applications make extensive use of such variables, there’s nothing wrong with that. However, we’ve found that the most difficult part of creating design patterns with ActionScript 3.0 is in making use of graphic materials and movie clips.

The enigmatic part of the Decorator is in setting it up. In order to see what I mean, take a look at the class diagram in Figure 1.

Figure 1: Decorator Class Diagram

Most of the details about the way this design pattern works are in our book, but I think a discussion of some of the features of this pattern would be helpful to point out a couple of things that struck me as a bit enigmatic.

In looking at what varies, we find that the variation is responsibilities of an object without sub-classing—in other words, use delegation. Of all of the things that can vary in a program structure, those assigned to the Decorator still need further clarification. As you will see in the next section, the Decorator seems to even contradict its own element of variation because it double-subclasses. However, once everything is straightened out, you will find the Decorator example we use to be very simple to implement and even use in a real live work situation.

An Abstract Class as a Subclass

One of the most unusual elements of the Decorator pattern is the fact that the abstract class, Decorator, is a subclass of the base abstract class, Component. The concrete component classes derived directly from the Component class act in a very similar way as the concrete decorator classes. This is because they have an almost identical interface. However, the concrete decorator classes wrap a Component reference inherited from the Decorator.

In some Decorator designs, the wrapper is actually in the abstract Decorator class. They are set up with a constructor in the abstract class itself, but as you know, ActionScript 3.0 has no abstract classes. While it might be possible in the ersatz abstract classes we use in AS3, a constructor seems to be superfluous. First, all of the decorators are typed as components in our design. You will see:

private var block:Component=new ConcreteComponent();
…
block = new ConcreteDecorator1(block);

That’s possible because the abstract Decorator class extends the abstract Component class. Even though the object is instantiated using Component typing, the same interface is inherited in the concrete decorators because their parent class (Decorator) inherits the interface of the Component class.

Time Out: At this point your brain may be saying, I should have listened to my mother who told me to stay away from those design pattern hoodlums. They’re nothing but trouble, and you’ll rue the day that you had anything to do with them. Why don’t you work for your nice cousin, the drug dealer? Well maybe you’re not thinking that, but that kind of code can jolt your brain. It’s perfectly normal, and it’ll go away in 9-10 years or when you die. See? Your mother was right, just like when she told your sister not to date guys with the nickname, killer.

Second, the design suggests that the concrete decorators be instantiated by wrapping the component instance. That would mean that the constructors would have to override the parent class constructor function. I don’t suppose there’s anything wrong with that, but I saw nothing to be gained from it. In their work, the Freemans (Head First Design Patterns) similarly did not include the wrapper in the abstract Decorator, even though Java does have an abstract class modifier. In any event, the decorator wraps the component and that allows the component and decorator elements to share much of the design’s structure.

Creating and Using Shape Components and Decorators

Other than the fact that the Decorator abstract class is a subclass of the Component abstract class and the Decorator wraps the Component class, the rest of the design is pretty straightforward. To understand this pattern, I believe that we’d be best served by starting with the results and then drilling down to see how it was done. Figure 2 shows what you will see with the default settings in the Client class.

Figure 2: Three Decorators and one Component

To both illustrate what’s happening and separate the decorator and component objects, I used a simple design. The black rounded rectangle is a component instance and the three colored round “filters” are decorators. The black component uses a solid fill and the decorators use 50% alpha fills. With this design, adding additional decorators and components is simple. Just add another concrete decorator or component class. Any shape can be used as either component or decorator.

The Component and Decorator Abstract Classes

In this example, both the base and sub-base classes have been kept simple. Keep in mind that this Decorator pattern is set up to be easy to use and practical at the same time. We’ll begin with the Component class. All it does is to provide the interface for the pattern. It has a single method, getFigure(), that can be used by both the Components and Decorators. It returns a Shape object.

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

//Component
//Abstract class: Do not instantiate
package
{
	import flash.display.Shape;
 
	public class Component
	{
		public var figure:Shape=new Shape();
 
		public function getFigure():Shape
		{
			return figure;
		}
	}
}

That’s not difficult at all. Any reference to a Shape object as a return object requires us to import the Shape class, but otherwise, it’s just a plain vanilla return function.

The base Decorator class is also very simple to build. Because it extends the Component class, it too inherits the single getFigure() method; so there’s no need to include it again. However, as you can see in the class diagram, it needs to hold a reference to the Component class. In fact, that’s about all it contains that you need to include in the code as can be seen in the following listing:

1
2
3
4
5
6
7
8
9

//Decorator
//Abstract class: Do not instantiate
package
{
	public class Decorator extends Component
	{
		protected var block:Component;
	}
}

Keep in mind that the Decorator is an abstract class, and like all abstract classes, you do not instantiate it. Just because it is a subclass does not mean it can be instantiated.

Some of you who have read the Freemans’ Head First Design Patterns chapter on the Decorator (the URL to which is at the end of this post) may have noticed that they did include or re-implement the main operation ( getDescription()) in the Decorator. However, they did so as an abstract method, which is available in Java but not in ActionScript 3.0. Further, they concatenated another element in their concrete decorators. Nothing is being concatenated to the Shape object in this example, and it wouldn’t be possible anyway—as a concatenation at least.

The Concrete Component and Decorator Classes

Given that this Decorator example is very simple and has only a single method, you will not see a lot differences between the concrete component and the decorators. However, that makes it all the easier to implement and better understand what’s going on. First of all, the ConcreteComponent class extends the Component class. The constructor function creates a simple Shape object. Because it is a subclass of the Component class, it has the getFigure() method and the Shape typed figure property. This may seem to be an unnecessary redundancy because the constructor should take care of creating the shape; however, it still needs the getFigure() method to return it to a request by the Client class.

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

//ConcreteComponent
package
{
	public class ConcreteComponent extends Component
	{
		public function ConcreteComponent()
		{
			figure.graphics.beginFill(0x000000,1 );
			figure.graphics.drawRoundRect(100,100,250,200,8);
			figure.graphics.endFill();
		}
	}
}

You can create as many concrete component classes as you want. Here we’ve just created one to keep it simple. Further on in this post, you will be given an opportunity to add more concrete component classes in a contest involving the Decorator design pattern.
Next, we will create the three decorator classes. You will note that instead of drawing a rounded rectangle, each draws a circle and each uses 50% alpha instead of 100%. Also, the decorator constructors wrap a Component instance. The Shape is created in the getFigure() operation which overrides the same operation in the Constructor class. We could have placed the Shape construction in the constructor function like we did with the ConcreteComponent class but chose not to in order to suggest more flexibility. Besides, the constructor function really should not be used for too much serious work. (See Miško Hevery’s article on making the constructor doing real work.) The following three class are identical except for their names and the fill color of the circles:

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

//Concrete Decorator
package
{
	import flash.display.Shape;
 
	public class ConcreteDecorator1 extends Decorator
	{
 
		public function ConcreteDecorator1(block:Component)
		{
			this.block = block;
		}
 
		public override function getFigure():Shape
		{
			figure.graphics.beginFill(0xff0000,.5 );
			figure.graphics.drawCircle(225,100,100);
			figure.graphics.endFill();
			return figure;
		}
	}
}

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

//Concrete Decorator
package
{
	import flash.display.Shape;
 
	public class ConcreteDecorator2 extends Decorator
	{
 
		public function ConcreteDecorator2(block:Component)
		{
			this.block = block;
		}
 
		public override function getFigure():Shape
		{
			figure.graphics.beginFill(0x00ff00,.5 );
			figure.graphics.drawCircle(225,200,100);
			figure.graphics.endFill();
			return figure;
		}
	}
}

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

//Concrete Decorator
package
{
	import flash.display.Shape;
 
	public class ConcreteDecorator3 extends Decorator
	{
 
		public function ConcreteDecorator3(block:Component)
		{
			this.block = block;
		}
 
		public override function getFigure():Shape
		{
			figure.graphics.beginFill(0x0000ff,.5 );
			figure.graphics.drawCircle(225,300,100);
			figure.graphics.endFill();
			return figure;
		}
	}
}

First, note the fact that literals are used for the colors, location and size. You may be thinking that doesn’t provide a lot of runtime flexibility with the shapes. Actually, it’s not that big of a deal. If you want, you can add parameters to the getFigure() operation without losing stride. However, the focus is on what the concrete decorators do and how they can be used as objects to change a concrete component; so for the time being don’t worry about adding parameters. (You can add parameters later.)

The Client

In many of the more recent examples, we’ve been adding user interfaces (UI) to the Client class for making requests from a patterned program in both Flex and Flash. In this example, we do not for two reasons. First, by using a few requests in the client not associated with a UI, you can clearly see how to make requests from the Decorator. Secondly, we’re having a contest where you will be providing your own UI in either Flash or Flex using ActionScript 3.0. (See The ActionScript 3.0 Decorator Design Pattern Contest for rules). For now, though, here’s the Client 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

//Client for Decorator Design Pattern
package
{
	import flash.display.Sprite;
 
	public class Client extends Sprite
	{
		private var block:Component=new ConcreteComponent();
 
		public function Client()
		{
			addChild(block.getFigure());
 
			block = new ConcreteDecorator1(block);
			addChild(block.getFigure());
 
			block = new ConcreteDecorator2(block);
			addChild(block.getFigure());
 
			block = new ConcreteDecorator3(block);
			addChild(block.getFigure());
		}
	}
}

In looking at the requests in the Client everything is centered on the block Component object. The object is first typed as a Component and then instantiated as a ConcreteComponent. The rest of the Client class does little more than make requests through the Component.getFigure() method. Each of the decorators is created by the desired concrete decorator wrapping the block object. Of course each concrete decorator is used just once and added to the DisplayObjectContainer and then destroyed as the block instance is re-instantiated with a new concrete decorator.

Into the Lunch Bucket

Now then, some of you may be thinking, that’s not so bad, and you’d be right. Sometimes the more daunting design patterns turn out to be pretty simple and sensible after all. You can add more concrete component classes by copying, pasting and renaming the ConcreteComponent class to ConcreteComponentA, etc. Change the Shape object in the new concrete component class, and Bob’s your uncle, it’s done! Likewise, you can do the same with concrete decorators. Add and change them all you want, and you’ll see that the Decorator design pattern structure handles them all with aplomb. Nothing falls apart or goes boom! It just keeps on truckin’.

You can see the Least Knowledge principle at work here. In part, you can see it in how the changes in the Component are delegated to the Decorator. Also, note that you need not drill down to access the different decorators. One dot does the trick (e.g., block.getFigure()) to bring up both the concrete component and decorators.

Finally, you can get a Free Chapter on the Decorator Design pattern from the Freeman’s Head First Design Patterns book. All of the examples are in Java, but it’s full of good stuff about using the Decorator, and all of it can be extrapolated for using with ActionScript 3.0. (Did I mention it’s free?)

So between our chapter on the Decorator in our book, this post about the Decorator, and the Freeman’s Decorator chapter, this is one design pattern you ought to be able to use in your work. To get started, why not enter our first Golden Lunch Bucket Contest? To practice, here’s what you can do (and see how freakin’ easy the pattern is to use):

1. Create a new concrete decorator with an entirely different Shape and add it to the program.
2. Change the existing Shape in the concrete component and add a new concrete component with yet another shape.
3. Change the Client to execute the program with the new concrete decorator and new and changed concrete component

That ought to do it for this Lunch Bucket Design Pattern. Be sure to take a look at the first Golden Lunch Bucket Contest that uses the design pattern in this post!

Okay, here’s a chance for Fame and Fortune. (We’ll supply the former; you supply the latter.) On Monday, April 27 you’ll find a new ActionScript 3.0 Easy and Practical Decorator Lunch Bucket Pattern on this blog. The contest will begin on Monday, April 27 and end Friday May, 22–2009. (That’s not a lot of time! But it should not take a lot of time to make the changes.) You can download the Decorator files here .

The contest is to see if you can change the Decorator design pattern in the new post, ActionScript 3.0 Easy and Practical Decorator Design Pattern.
Using the provided Component class (no changes allowed) and the provided Decorator class (no changes allowed) add new or changed Concrete Components and/or Concrete Decorators to make the most interesting program using the Decorator Design Pattern.

We have four age categories, and each category will have 1st, 2nd, and 3rd prizes. The Grand Prize will be given to the very best entry, regardless of age. Here are the categories:

• Under 18
• 18-25
• 26-40
• Over 40

All winners will be displayed on this blog along with their entries and photos. Read on to learn the rules.

The Rules

1. You cannot change the code in the Component Class
2. You cannot change the code in the Decorator Class
3. You can only request concrete decorators or components from the Client class
4. You cannot change the interfaces or signatures in the concrete decorator or component classes
5. You cannot add bitmapped graphics or load external bitmapped or SWF files.
6. You can add UI components to the Client class only and only for making requests for concrete decorators or components.
7. All entries must be compacted in .zip format
8. Either Adobe Flex Builder or Flash may be used—if it’s all code you could use Note Pad or TextEdit I suppose.
9. All ActionScript must be version 3.0

If any of the rules are broken, the entry will be disqualified.

All inquiries about the Contest must be made to the Comments Section of this blog entry. The reason is that if one person has a query, there’s usually a dozen more with the same question, and it saves time to respond to a single query than many. (No email inquires will be answered).

All entries must have the following:

Name
Age
Subject Line in email: Golden Lunch Bucket Contest
Attached .zip file with your entry

Email entries to: Bill Sanders: wdsanders@comcast.net

No entries will be accepted after May 22, 2009