ActionScript 3.0 Design Patterns

I ran across the Flyweight design pattern when looking for a pattern that could be used to speed up placing objects on the stage in a Flash application using ActionScript 3.0. The Flyweight name implies a somewhat insignificant design pattern, but after working with it for a few months I found it to be both powerful and informative. It is powerful in that it is one pattern that actually speeds up operations, and it’s informative in that key OOP concepts are used and illuminated in it. It’s also one that has taken a while to really put together right—a process I’m still working on. Because this is a work in progress, I’d like to invite any and all developers with an interest in ActionScript 3.0 and design patterns to comment.

The Flyweight Basics

Imagine a situation where you want lots of buttons on the stage as a UI for information access. This is a pretty common situation and so a worthwhile effort if it works as it’s supposed to. You can use a component button from the Button class by importing it from fl.controls or build one using the SimpleButton class. The intrinsic features of a button are pretty similar—the way it works, looks and listens for events. However, the extrinsic features of buttons depend on their context. The position of a button on the stage, what it does with events, and what actions it calls forth are context dependent features. In a nutshell, the Flyweight separates the intrinsic from the extrinsic. The intrinsic state of an object is stored in the Flyweight. This information is context free and can be shared with all buttons. In fact, the Flyweight is a shared object. So instead of having several objects, you have one objects shared by many.

The example used by the Gang of Four is an application that uses the Flyweight is a word processor. Each character (glyph) is an object, and a word document contains a lot of character objects that are constantly reused. The intrinsic state of a character, like the letter “e”, is pretty standard. However, the extrinsic state changes with its position on the page (context). By reusing a single intrinsic state for each object, you can save a lot of time over creating a new one each time it’s needed on a page. So, the Flyweight stores the intrinsic state and then just changes the Flyweight’s extrinsic state to the desired position on the page. In the application planned for this article, instead of glyphs, we’ve got buttons, and just like the glyphs, all we need to do is the position them on an x/y grid.

Flyweight Overview

To get started, take a look at the Flyweight class diagram :

Flyweight Class Diagram

Like all of these diagrams, it takes some study to see what’s going on. (It took me a lot.) You’ll find some interesting relationships among the classes in the Flyweight pattern. First of all, the relationship between the FlyweightFactory and the Flyweight is one of aggregation. The factory class is the aggregator and the flyweight interface is the aggregate. You can think of the factory class owning the interface in the context of aggregation.

Second, the design pattern specifically includes the Client as a class. This means that the client has a responsibility in the pattern and references Participant classes. About half the patterns in the GoF book include a Client class. Chandima’s article on the Composite pattern also includes a Client class in the pattern. (If you see a gray Client class in a diagram that means that the Client is not part of the pattern, but is a handy tool to show which Participants interact with the Client class.)

Third, the pseudocode annotation associated with the FlyweightFactory class helps to give you a better idea of what is going on in the class. These annotations are extremely helpful in understanding exactly how the operations are implemented. However, as you have no doubt learned, when you implement in ActionScript 3.0 you need to design for ActionScript 3.0, which can be significantly different from say Java or C# where you will find most examples.

An Abstract Flyweight in ActionScript 3.0

One of the problems in creating any of the patterns described by GoF or in the Freemans’ wonderful book, HeadFirst Design Patterns, is that they’re written in SmallTalk or Java. What’s more, they use some of the really cool built-in features of those languages that are not available in ActionScript 3.0. The Flyweight is no exception, plus the fact that it’s not expanded in HeadFirst Design Patterns. So getting started has meant finding out how to work out a sensible alternative to hash tables (associative arrays) and decide whether to use an abstract class (which is not available in ECMAScript 4) or an interface, that is.

Fortunately for me, Jim Kremens, a top notch NYC Flex 2 developer, had an example of the Flyweight design pattern he shared with me. I made a few changes to suit my tastes, but it is basically Jim’s design. I swapped an interface with the “abstract class” (see Chandima’s article, Runtime Checks for Abstract Classes and Methods in ActionScript 3.0 on this blog.) Also, Jim used the Array class for creating an associative array, which works fine. However, the ActionScript 3.0 docs suggests using the Object class for associative arrays, and so I changed the Array class to an Object class. That’s not a lot of changes, and Jim’s design is strong enough to incorporate the changes with very little alternations to the code. Finally, I made the miniscule changes reflecting the switch from Flex 2 to Flash CS3 API.

ActionScript Abstract Flyweight Example

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

package
{
	//Flyweight interface
	public interface IFlyweight
	{
		function build ():void;
	}
}
 
package
{
	//Flyweight Factory
	public class Factory
	{
		protected var objects:Object = {};
 
		public function Factory ()
		{
			objects["X"] = new FillObject();
		}
		public function Retrieve (key:String, ...rest):IFlyweight
		{
			switch (objects[key] != undefined)
			{
				case (true) :
					break;
				case (false) :
					objects[key] = rest[0];
					break;
			}
			return objects[key];
		}
	}
}
 
package
{
	//Concrete Flyweight: Fill
	public class FillObject implements IFlyweight
	{
		public function FillObject () {}
		public function build ():void
		{
			trace ("Build FillObject");
		}
	}
}
 
package
{
	//Concrete Flyweight: Stroke
	public class StrokeObject implements IFlyweight
	{
		public function StrokeObject () {}
		public function build ():void
		{
			trace ("Build StrokeObject");
		}
	}
}
 
package
{
	//Client class
	import flash.display.Sprite;
 
	public class FlyweightTest extends Sprite
	{
 
		public function FlyweightTest ()
		{
			var factory:Factory=new Factory  ;
 
			var x:IFlyweight=factory.Retrieve("X");//"X" already exists
			x.build ();
			var y:IFlyweight=factory.Retrieve("Y",new StrokeObject  );
			y.build ();
			var z:IFlyweight=factory.Retrieve("Z",new FillObject  );
			z.build ();
		}
	}
}

As you can see from both the code and the class diagram, the Client class (FlyweightTest) does not get stroke and fill objects directly from the concrete flyweights (stroke and fill) nor the IFlyweight interface. Instead it relies on the Factory class. To make this whole thing fly (no pun intended), Jim used the keyword, …rest. By placing the …rest keyword in a function’s parameter (called a rest parameter), the function will accept any number of comma-delimited arguments. In the Retrieve method in the Factory class, the rest parameter can be used to identify the specified concrete flyweight identified by the associative array’s key word. If the key is recognized as existing already in the case statement, the existing instance is returned. Otherwise the Factory cooks up a new instance. We can see this in the output:

Build FillObject
Build StrokeObject
Build FillObject

The first FillObject with the X key was already built in the Factory ; thus, it was not undefined. So, it just jumped out of the switch structure and returned the X object, which was a FillObject. The second key, Y, was a StrokeObject that had not been defined, and so the factory built one. Likewise, with the Z key, no key named Z had been defined; so it created one, which happened to be another FillObject.

The concrete flyweights, both of which have implemented the IFlyweight interface, hold an intrinsic state. However, because we have no extrinsic state as a parameter, we may have a shared object, but we have no information for the extrinsic state. Further, do we really have a shared object? Remember that the concrete Flyweight can be a shared object. So to test the example code for shared objects, we need to change the client (FlyweightTest) so that multiples of the shared object can be seen. To do this, I created a new concrete flyweight, FlyButton, representing the object that I eventually want to be used as a shared object. Likewise, I created a new client class to test the whole thing (FlyweightShared). The following two classes can be placed with the other participants and then tested in either Flash CS3 or Flex 2:

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

package
{
 
	public class FlyButton implements IFlyweight
	{
		public function FlyButton ()
		{}
		public function build ():void
		{
			trace("I'm a shared button. I think...");
		}
	}
}
 
package
{
package
{
	//Client class
	import flash.display.Sprite;
 
	public class FlyweightShared extends Sprite
	{
 
		public function FlyweightShared ()
		{
			var factory:Factory=new Factory;
 
			var firstOne:IFlyweight=factory.Retrieve("ButtonFly");
			firstOne.build ();
			var secondOne:IFlyweight=factory.Retrieve("ButtonFly");
			secondOne.build ();
			var thirdOne:IFlyweight=factory.Retrieve("ButtonFly");
			thirdOne.build ();
		}
	}
}

In addition, we’ll need to make a slight change to the Factory class. Now it reads:

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
{
	//Flyweight Factory
	public class Factory
	{
		protected var objects:Object = {};
 
		public function Factory ()
		{
			objects["ButtonFly"] = new FlyButton();
		}
		public function Retrieve (key:String, ...rest):IFlyweight
		{
			switch (objects[key] != undefined)
			{
				case (true) :
					break;
				case (false) :
					objects[key] = rest[0];
					break;
			}
			return objects[key];
		}
	}
}

This time, I got the same output for all of the three variables in the output window:

I'm a shared button. I think...
I'm a shared button. I think...
I'm a shared button. I think...


You may be wondering the same thing I am: “Is this really a shared object, or does it just instantiate three instances like you could do using var button:Button = new Button()?” If it’s a shared object, then we ought to have a much speedier and less processor-intensive structure. Otherwise, we’ve just succeeded in a convoluted way of creating a button. Tune in next time to see what’s up or leave a comment to straighten me out on this. In addition, we need to so something about that pesky extrinsic state, not to mention using a real button and not just a trace statement.

Related posts:

1. Composite Pattern: Book (Part 1)