ActionScript 3.0 Design Patterns

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.

Related posts:

1. ActionScript 3.0 Easy and Practical Decorator Design Pattern
2. Beginners OOP & Design Patterns in ActionScript 3.0 Post 1 : Rolls-Royces in the Junk Yard
3. Beginners OOP & Design Patterns in ActionScript 3.0 Post 2: Code Organizer