Air traffic controllers look at virtual simulations of hundreds of aircraft. The images on a screen give the ATCs the information they need for separating the many planes under their control. The hub airports such as Chicago O’Hare and Dallas-Ft. Worth have to juggle hundreds of simultaneous flights arriving at and departing from their respective airports. To maintain accuracy, images that display position, heading, altitude, level flight, ascent and descent must be updated frequently, accurately and quickly. In looking over the set of design patterns set forth by Gamma, et al, the Flyweight pattern offers the following:

• An application uses a large number of objects
• Storage costs are high because of the sheer quantity of objects
• Most object state can be made extrinsic
• Many groups of objects may be replaced by relatively few shared objects once extrinsic state is removed
• The application doesn’t depend on object identity. Since flyweight objects may be shared, identity tests will return true for conceptually distinct objects

That pretty well fills the bill for what is required. We need a large number of objects (airplane images), the sheer quantity has high storage costs, the extrinsic state such as heading, horizontal position and vertical position can be made extrinsic, once extrinsic state is removed, a few objects can be used to represent groups of objects, and the application is not dependent of object identity. This is not to say that one cannot be distinguished from the other, but rather the object identity is relative to its extrinsic characteristics.Figure 1 shows the basic class diagram.

Figure 1: Class Diagram

The key elements of the class include the following:

• The Flyweight class, (an abstract class or interface) with the operation with parameters for the extrinsic states.
• A Flyweight Factory that aggregates the Flyweight class. (The ball at the end of the aggregation arrow indicates that multiple aggregations may exist.)
• A Concrete Flyweight contains the extrinsic states and the intrinsic states. This is a shared object
• (Optionally) An unshared concrete Flyweight containing the extrinsic state but cannot be shared.
• A Client participant. The Client class in this design pattern has a responsibility and has acquaintance relations with both the concrete flyweights and the factory classes.

The primary functionality of the Flyweight design pattern is the ability to quickly make multiple copies of an object by creating one instance and sharing it for multiple re-uses. The instances and reference to the instances are generated in a Flyweight Factory that aggregates the Flyweight interface or abstract class. The intrinsic value shared is stored in a concrete Flyweight and then shared for multiple uses by assigning different extrinsic values. A Flyweight shared object is one with a common intrinsic value that is used by all references to the Flyweight. The extrinsic values provide the shared object with contextual values that are not shared.

Aggregation and Acquaintance

A key relationship between the Flyweight and Flyweight Factory is that of aggregation. The factory participant is the aggregator and the flyweight the aggregatee. The nature of the aggregation relationship is unique in that the aggregator holds a dependent reference in the sense that its life is dependent on the life of the aggregatee. The following shows what such a relationship looks like at the point where it occurs in the code:

public function getIntrinsic (key:String,... rest):FlyweightPlane

In this case assigning the return type as FlyweightPlane, the Flyweight interface or abstract class, makes the aggregation. The aggregate can only work as long as the FlyweightPlane is extant, and so stands as an example of aggregation in the sense that that have identical lifetimes.The Client participant is connected to the other participants through acquaintance. It has an acquaintance with the Factory and Concrete Client[s]. For instance, declaring an instance of the Factory in the Client participant establishes an acquaintance:

1
2
3
4

private var planeFactory;
…
planeFactory=new PlaneFactory()
plane1=planeFactory.getIntrinsic("east");

Likewise, the Client participant establishes an acquaintance with the Concrete Flyweight, but far more indirectly. For example, the line,

plane1.doPlane (xPos,yPos,w,h,curve);

creates an acquaintance through the PlaneFactory aggregation of the Flyweight and its subclass, a Concrete Flyweight. In this case, the acquaintance is through the key Flyweight operation (doPlane) implemented in the Concrete Flyweight.

Intrinsic and Extrinsic States

Another defining characteristic of the Flyweight is the handling of intrinsic and extrinsic states. An intrinsic state is immutable and cannot be changed, and as such can be used by other references to the same instance. The intrinsic state is stored in the Concrete Flyweight. For example, a car has an engine (intrinsic state) however the car has many different contexts (extrinsic state), such as it’s location, whether it is moving or stopped and other states that cannot be shared (like the same parking place).The Flyweight establishes an operation to specify the possible extrinsic states as parameters. The Client participant is responsible for supplying the extrinsic state. For example, the line,

plane1.doPlane (xPos,yPos,w,h,curve);

requires values for five extrinsic states. The horizontal and vertical position of the sprite, its width and height and the curve value of a rounded rectangle are the included extrinsic parameters. The Following line

plane1.doPlane (134,220,60,10,20);

draws a button-shaped rectangle positioned at:

• horizontal position = 134
• vertical position = 220
• rounded rectangle width = 50
• rounded rectangle height = 10
• rounded rectangle curve=20

These values are all extrinsic states of the object provided by the client.An intrinsic state can be anything sharable. For example, in the following examples, the intrinsic value is the color. All of the objects have the same color even though the instance references have different horizontal and vertical positions.

The Flyweight Factory

Creating multiple references to the same instance is possible because of the Flyweight Factory. The basis of the Flyweight Factory is its ability to recognize an extant instance and re-use it by adding it to an associative array (or hash table). This has the effect of re-using the same object’s intrinsic state by adding it to the array. In most discussions of the Flyweight Factory, hash tables are used. Both C# and Java, for example, use hash tables. ActionScript 3.0 has no hash tables so associative arrays used to effect equivalent results. Associative arrays are built using the Object class rather than the Array class. (None of the Array class methods or properties are available when keys are used instead of numeric indices.)

Shared Object

With the creation of a new element of an associative array each key corresponds to a property name. The associated value and name establish a key and value pair. If the key is undefined, the associative array creates a new one. The following script shows a generic 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

public class Factory
{
 //Associative Array
 protected var storeFlyweight:Object={};
 
 public function Factory()
 {
  getFlyweights ();
 }
 
 private function getFlyweights ()
 {
  storeFlyweight["first"]=new ConcreteFlyweight(intrinsic);
  storeFlyweight["second"]=new ConcreteFlyweight(intrinsic);
 }
 
 public function getIntrinsic (key:String,... rest):Flyweight
 {
  switch (storeFlyweight[key] != undefined)
  {
   case true :
    break;
   case false :
    storeFlyweight [key]=rest[0];
    break;
  }
  return storeFlyweight [key];
 }
}

Unshared Objects

As can be seen, the Flyweight Factory is pretty much like any other factory class except that it returns multiple copies of a single instance. In other words, it’s a shared object. In looking at Factory Method factories, you will not see this. For instance, the following example by Chandima Cumaranatunge (Sanders and Cumaranatunge, 2007) is for a simple factory and it deals with two different instances of an object:

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

public class Creator
{
	public static function simpleFactory(product:String)
	{
		if (product == "p1")
		{
			return new product1( );
		} else if (product == "p2") {
			return new product2( );
		}
	}
}

The result is that more objects are created resulting in more elements to be stored and displayed. Thus, rather than one instance, the results are multiple instances.

A Simple Flyweight Example: Making Balls

To get started, it’s best to start with a minimalist example so that all of the participants can be seen. In this set of examples, the focus is on the following participants:

• Flyweight
• Flyweight Factory
• Concrete Flyweight (Shared)
• Client

The Unshared Concrete Flyweight is not included since it is optional and at this level really is unneeded.The example does nothing more than create several instances of a ball object. Four of the balls are created using the Flyweight Factory and one is created by simply instantiating an instance of the ball object (Green). The unshared object is to illustrate that there’s no discernable difference in appearance of shared or unshared objects.

Abstract Flyweight

1
2
3
4
5
6
7
8
9
10

package
{
	//Abstract class Flyweight
	import flash.display.Sprite;
 
	public class FlyweightBall extends Sprite
	{
		function doCircle (xPos:uint,yPos:uint,radius:uint):void {}
	}
}

Flyweight Factory

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

package
{
 //Flyweight Factory
 public class BallFactory
 {
  protected var ballIntrinsic:Object={};
 
  public function BallFactory ()
  {
   ballIntrinsic["red"]=new FlyBall(0x990000);
   ballIntrinsic["yellow"]=new FlyBall(0xffff00);
 
  }
  public function getIntrinsic (key:String,... rest):FlyweightBall
  {
   switch (ballIntrinsic[key] != undefined)
   {
    case true :
     break;
    case false :
     ballIntrinsic[key]=rest[0];
     break;
   }
   return ballIntrinsic[key];
  }
 }
}

Concrete Flyweight

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

package
{
 //Concrete Flyweight
 
 public class FlyBall extends FlyweightBall
 {
  protected var fill: uint;
 
  public function FlyBall (fill:uint)
  {
   this.fill=fill;
  }
 
  override function doCircle (xPos:uint,yPos:uint,radius:uint):void
  {
   graphics.beginFill (fill);
   graphics.drawCircle (xPos,yPos,radius);
   graphics.endFill ();
  }
 }
}

Client

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

package
{
 //Client class
 import flash.display.Sprite;
 
 public class BallClient extends Sprite
 {
 
  //Client data to provide extrinsic state details
  private var xPos:uint;
  private var yPos:uint;
  private var radius:uint;
  private var cir1:FlyweightBall;
  private var cir2:FlyweightBall;
  private var cir3:FlyweightBall;
  private var cir4:FlyweightBall;
  private var cir5:FlyBall;
 
  public function BallClient ()
  {
   var ballFactory:BallFactory=new BallFactory;
 
   cir1=ballFactory.getIntrinsic("red");
   shuffle ();
   cir1.doCircle (xPos,yPos,radius);
   addChild (cir1);
 
   cir2=ballFactory.getIntrinsic("red");
   shuffle ();
   cir2.doCircle (xPos,yPos,radius);
   addChild (cir2);
 
   cir3=ballFactory.getIntrinsic("yellow");
   shuffle ();
   cir3.doCircle (xPos,yPos,radius);
   addChild (cir3);
 
   cir4=ballFactory.getIntrinsic("yellow");
   shuffle ();
   cir4.doCircle (xPos,yPos,radius);
   addChild (cir4);
 
   //Unshared--Not a Flyweight instance
   cir5=new FlyBall(0x009900);
   shuffle ();
   cir5.doCircle (xPos,yPos,radius);
   addChild (cir5);
  }
 
  private function shuffle ()
  {
   //Generate extrinsic states
   xPos=Math.round(Math.random() * 500);
   yPos=Math.round(Math.random() * 300);
   radius=Math.round(Math.random() * 100);
  }
 }
}

Figure 2 shows a typical output. (Because the radii and Cartesian coordinates are random, the output is different each time the application launches and what you see may be entirely different.)

The Flyweight’s only intrinsic value is the color, and when a Flyweight is created in the Factory, it is done so providing a color value. The name of the object is stored in the associative array, and when another request is made using the same name, the instance is shared with the new request. The extrinsic value are all provided by the Client using random values.

Figure 2: Four Flyweights and an Unshared Green ObjectShowing Single Instance with Multiple Elements

The problem with the ball example is that it is a take my word for it example. That is, it demonstrates nothing to convince or show that the two red and the two yellow balls are any different from the green one. It is useful insofar as the code shows that the green ball is not created in the same way as the others, but the consequences of that are not too clear.

Beyond Extrinsic: Instance External Properties

The way to show that a single instance contains multiple uses of a single object is to change a property of the instance to have an effect on all instances in the object. The extrinsic values can change the horizontal and vertical positions of the balls as well as the radius of each ball. So, while the two yellow balls in Figure 2 have different positions, they are still part of a single instance of the ball.One property that is not part of the extrinsic parameters is rotation. However, rotating a ball isn’t much help because all rotation angles look the same. So, now would be a good time to start building the air traffic control image representing a single aircraft. Thus, instead of a ball, this next example will use an airplane and different extrinsic values. However, rotation will not be one of these extrinsic values. That will be saved for the entire instance. The following application makes these adjustments.

Abstract Flyweight

1
2
3
4
5
6
7
8
9
10

package
{
 //Abstract class Flyweight
 import flash.display.Sprite;
 
 public class FlyweightPlane extends Sprite
 {
 	function doPlane (xPos:uint,yPos:uint,w:uint,h:uint,curve:uint):void {}
 }
}

Flyweight Factory

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

package
{
 //Flyweight Factory
 public class PlaneFactory
 {
  protected var rectIntrinsic:Object={};
 
  public function PlaneFactory ()
  {
   rectIntrinsic["red"]=new MakePlane(0x990000);
   rectIntrinsic["green"]=new MakePlane(0x009900);
   rectIntrinsic["blue"]=new MakePlane(0x000099);
 
  }
 
  public function getIntrinsic (key:String,... rest):FlyweightPlane
  {
   switch (rectIntrinsic[key] != undefined)
   {
    case true :
     break;
    case false :
     rectIntrinsic[key]=rest[0];
     break;
   }
   return rectIntrinsic[key];
  }
 }
}

Concrete Flyweight

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

package
{
 //Concrete Flyweight
 
 public class MakePlane extends FlyweightPlane
 {
  protected var fill: uint;
 
  public function MakePlane (fill:uint)
  {
   this.fill=fill;
  }
 
  override function doPlane (xPos:uint,yPos:uint,w:uint,h:uint,curve:uint):void
  {
   graphics.beginFill(fill);
   graphics.drawRoundRect(xPos,yPos,w,h,curve)
   graphics.endFill();
   graphics.beginFill(fill);
   graphics.drawRoundRect(xPos-18,yPos+17,45,10,9)
   graphics.endFill();
   graphics.beginFill(fill);
   graphics.drawRoundRect(xPos-7,yPos+37,25,7,12)
   graphics.endFill();
  }
 }
}

Client

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

package
{
 //Client class
 import flash.display.Sprite;
 
 public class PlaneClient extends Sprite
 {
  //Client data to provide extrinsic state details
  private var xPos:uint;
  private var yPos:uint=0;
  private var w:uint;
  private var h:uint;
  private var curve:uint;
  private var planeFactory:PlaneFactory;
  private var plane1:FlyweightPlane;
  private var plane2:FlyweightPlane;
  private var plane3:FlyweightPlane;
  private var plane4:FlyweightPlane;
  private var plane5:FlyweightPlane;
  private var plane6:FlyweightPlane;
 
  public function PlaneClient ()
  {
   planeFactory=new PlaneFactory ;
 
   plane1=planeFactory.getIntrinsic("red");
   place ();
   plane1.doPlane (xPos,yPos,w,h,curve);
   addChild (plane1);
   plane1.rotation=15;
 
   plane2=planeFactory.getIntrinsic("red");
   place ();
   plane2.doPlane (xPos,yPos,w,h,curve);
   addChild (plane2);
 
   plane3=planeFactory.getIntrinsic("blue");
   place ();
   plane3.doPlane (xPos,yPos,w,h,curve);
   addChild (plane3);
   plane3.rotation=0;
 
   plane4=planeFactory.getIntrinsic("blue");
   place ();
   plane4.doPlane (xPos,yPos,w,h,curve);
   addChild (plane4);
   plane4.rotation=25;
 
   plane5=planeFactory.getIntrinsic("green");
   place ();
   plane5.doPlane (xPos,yPos,w,h,curve);
   addChild (plane5);
   plane5.rotation=180;
 
   plane6=planeFactory.getIntrinsic("green");
   place ();
   plane6.doPlane (xPos,yPos,w,h,100);
   addChild (plane6);
   plane6.rotation=345;
  }
 
  private function place ()
  {
   //Generate extrinsic states
   xPos=250;
   yPos +=60;
   w=10;
   h=50;
   curve=20;
  }
 }
}

The Client supplies the values for the extrinsic parameters, but it can also add values for properties of the entire object beyond the extrinsic. An important element is to point out the different rotation values for the object pairs:

• red: plane 1-rotation= 15 ; plane2-rotation=none;
• blue: plane3 -rotation= 0 ; plane4-rotation= 25;
• green: plane5 -rotation= 180 ; plane6-rotation= 345;

When the overall rotation is viewed in the output, it’s clear that both images take the rotation value of the last airplane in the script for their group where a rotation value is specified. This can be seen in Figure 3.

Figure 3. Three objects with six airplanes

The red airplanes (plane1 and plane2 in the code) at the top of Figure 2 are at a 15° angle (0° is straight up). Because plane1 and plane2 are part of the same “red” instance, their angle is the same. Likewise with the other two pairs, even where one is assigned one rotation value and the other a different one, both images show the same rotation. The x and y values of the airplanes are relative to the instance in which each pair resides. The green airplanes have different noses because they have different values for the curve of the rounded rectangle the makes up the fuselage—made possible because each has an extrinsic value for the curve value of a rounded rectangle. So, while references to the same instance have the same intrinsic value (color in this case), the extrinsic values distinguish one from the other even though they are part of the same flyweight instance. Because rotation is a property of the DisplayObject class, it treats all instances as separate entities, but not the multiple references to the same instance. So when an instance is rotated, all references to that instance are rotated in the same direction.

Multiple Updates

Now that there’s some kind of grasp on what’s going on with flyweights and how they are structured, it’s time to really put them to work. Going back to the original purpose of this Flyweight to place many images on the screen quickly using as little memory as possible and update them regularly, this next application constantly refreshes 50 different images. Each reference to a single instance is stored in an array to quickly add images to the screen in a test of concept. The application employs the following code:

Abstract Flyweight

1
2
3
4
5
6
7
8
9
10
11

package
{
 //Abstract class Flyweight
 import flash.display.Sprite;
 
 public class FlyweightPlane extends Sprite
 {
 function doPlane (xPos:uint,yPos:uint,w:uint,h:uint,curve:uint):void
 {}
 }
}

Flyweight Factory

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
{
 //Flyweight Factory
 public class PlaneFactory
 {
  //Associative Array
  protected var planeIntrinsic:Object={};
 
  public function PlaneFactory ()
  {
   getPlane ();
  }
 
  private function getPlane ()
  {
   planeIntrinsic["east"]=new MakePlane(0x990000);
  }
 
  public function getIntrinsic (key:String,... rest):FlyweightPlane
  {
   switch (planeIntrinsic[key] != undefined)
   {
    case true :
     break;
    case false :
     planeIntrinsic[key]=rest[0];
     break;
   }
   return planeIntrinsic[key];
  }
 }
}

Concrete Flyweight

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

package
{
 //Concrete Flyweight
 
 public class MakePlane extends FlyweightPlane
 {
  protected var fill: uint;
 
  public function MakePlane (fill:uint)
  {
   this.fill=fill;
  }
 
override function doPlane (xPos:uint,yPos:uint,w:uint,h:uint,curve:uint):void
  {
   graphics.beginFill(fill);
   graphics.drawRoundRect(xPos,yPos,w,h,curve)
   graphics.endFill();
   graphics.beginFill(fill);
   graphics.drawRoundRect(xPos-18,yPos+17,45,10,9)
   graphics.endFill();
   graphics.beginFill(fill);
   graphics.drawRoundRect(xPos-7,yPos+37,25,7,12)
   graphics.endFill();
  }
 }
}

Client

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

package
{
 //Client class
 import flash.display.Sprite;
 import flash.utils.setInterval;
 import flash.utils.Timer;
 import flash.events.TimerEvent;
 
 public class Apprentice extends Sprite
 {
  //Client data to provide extrinsic state details
  private var xPos:uint;
  private var yPos:uint=50;
  private var w:uint;
  private var h:uint;
  private var heading:uint;
  private var curve:uint;
  private var plane:Array;
  private var sweepTime:uint=1000;
  private var ee:Boolean=false;
  private var planeFactory:PlaneFactory;
  private var sweep:Timer;
 
  public function Apprentice ()
  {
   planeFactory=new PlaneFactory ;
   plane=new Array();
 
   upDate ();
   sweep=new Timer(sweepTime,0);
   sweep.addEventListener("timer",newPos)
   sweep.start();
  }
 
  private function makeGroup ():void
  {
   yPos=80;
   heading=90;
   for (var air:uint=0; air < 50; air++)
   {
    plane[air]=planeFactory.getIntrinsic("east");
    place ();
    plane[air].doPlane (xPos,yPos,w,h,curve);
    addChild (plane[air]);
    plane[air].rotation=heading;
   }
   plane[0].x=700,plane[0].y=150;
  }
 
  private function place ():void
  {
   //Generate extrinsic states
   xPos=Math.round(Math.random()*500);
   yPos= Math.round(Math.random()*400);
   w=10;
   h=50;
   curve=20;
  }
 
  private function cleanup ():void
  {
   for (var air:uint=0; air < 50; air++)
   {
   removeChild (plane[air]);
   plane[air]=null;
   }
  }
 
  public function newPos (e:TimerEvent):void
  {
   upDate()
  }
 
  private function upDate ():void
  {
   if (ee)
   {
    cleanup ();
   }
   makeGroup ();
  }
 }
}

This flyweight application is very similar to the others except that it uses a timer to refresh the images and an array to hold the different instance references. The idea is to simulate the changing positions of aircraft, but instead of changing the actual x and y positions as the aircraft enter the traffic pattern prior to landing, it uses random positioning values to demonstrating quickly rendering large number of images to the screen in different positions.

The Sorcerer’s Apprentice

The application refreshes the images every second, but what occurs is unexpected. Figures 4-6 show the rapid increase of images on the screen:

Figure 4: The expected number of images appears using a single instance.

Figure 5: After a few seconds, it becomes apparent that the associative array is loading the new references on top of the old ones.

Figure 5: Eventually the images become unrecognizable as more and more images are placed

The results of this application reminded me of Mickey Mouse playing the sorcerer’s apprentice in Disney’s animated classic, Fantasia. Based on a poem by the same name by Johann Wolfgang von Goethe, the following lines showed that Goethe knew we’d be working with sprites sooner or later:

Every step and saying
That he used, I know,
And with sprites obeying
My arts I will show.

In the animated 1940 film Mickey Mouse decides to use the sorcerer’s magic to do his chores—carrying water from the well up to a tank to be filled. He uses magic on some brooms and they begin carrying the water up to the tank, but soon the tank fills and he doesn’t know the magic words to stop them, and they just keep on going very much like this application.

The Wrong Spell

The method used to refresh the sprites removed both the image from the stage and set the elements to null.

1
2
3
4
5
6
7
8

private function cleanup ():void
{
 for (var air:uint=0; air < 50; air++)
 {
 removeChild (plane[air]);
 plane[air]=null;
 }
}

However, the results show that the cleaup() method simply does not work. So what’s going on? How is it possible for the array to keep adding to the number of images even though the array and all of the elements are cleared from the stage and set to null? The answer is that the method addresses the wrong array. This shows that the Array class used to generate references to the instance of the Flyweight object did not store those references. Rather, they are stored in the associative array in the Flyweight Factory. Therefore, we need a method in the Flyweight Factory to clear them out with every update. Fortunately, it’s quite simple. All that is required to set a given key in the associative array to null. So, in the above example, the following line will do the trick.

planeIntrinsic["east"]=null;

Because a single instance was generating several references with position information and other extrinsic values, every time the set of 50 images was refreshed, it just added to those stored in the associative array. The Array class worked to generate new references to the associative array, but it never removed any. All that the cleanup script did was to empty the contents of the array that shoved more references into the instance held in the associative array.

Multiple Instances and Many References

The final step is to install a system that deals with multiple instances, with each instance referenced by an updated set of new extrinsic values. To continue with the set used so far, this final application will take four instances with each on a different heading and updated using random values. The updates will be every 3 seconds (or 3000 milliseconds) and each set will display a set of 200 images based on four instances, each represented by a different color. The following script finally pulls all of the parts together:

Flyweight

1
2
3
4
5
6
7
8
9
10
11

package
{
 //Abstract class Flyweight
 import flash.display.Sprite;
 
 public class FlyweightPlane extends Sprite
 {
   function doPlane (xPos:uint,yPos:uint,w:uint,h:uint,curve:uint):void
   {}
 }
}

Flyweight Factory

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
{
 //Flyweight Factory
 public class PlaneFactory
 {
  //Associative Array
  protected var planeIntrinsic:Object={};
 
  public function PlaneFactory ()
  {
   getPlane ();
  }
 
  private function getPlane ()
  {
   planeIntrinsic["east"]=new MakePlane(0x990000);
   planeIntrinsic["west"]=new MakePlane(0x009900);
   planeIntrinsic["north"]=new MakePlane(0x000099);
   planeIntrinsic["south"]=new MakePlane(0xFF6600);
  }
 
  public function getIntrinsic (key:String,... rest):FlyweightPlane
  {
   switch (planeIntrinsic[key] != undefined)
   {
    case true :
     break;
    case false :
     planeIntrinsic[key]=rest[0];
     break;
   }
   return planeIntrinsic[key];
  }
 
  public function clearPlane ()
  {
   planeIntrinsic["east"]=null;
   planeIntrinsic["west"]=null;
   planeIntrinsic["north"]=null;
   planeIntrinsic["south"]=null;
   getPlane ();
  }
 }
}

Concrete Flyweight

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

package
{
 //Concrete Flyweight
 
 public class MakePlane extends FlyweightPlane
 {
  protected var fill: uint;
 
  public function MakePlane (fill:uint)
  {
   this.fill=fill;
  }
 
override function doPlane (xPos:uint,yPos:uint,w:uint,h:uint,curve:uint):void
  {
   graphics.beginFill(fill);
   graphics.drawRoundRect(xPos,yPos,w,h,curve)
   graphics.endFill();
   graphics.beginFill(fill);
   graphics.drawRoundRect(xPos-18,yPos+17,45,10,9)
   graphics.endFill();
   graphics.beginFill(fill);
   graphics.drawRoundRect(xPos-7,yPos+37,25,7,12)
   graphics.endFill();
  }
 }
}

Client

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

package
{
 //Client class
 import flash.display.Sprite;
 import flash.utils.setInterval;
 import flash.utils.Timer;
 import flash.events.TimerEvent;
 
 public class CrowdedSky extends Sprite
 {
  //Client data to provide extrinsic state details
  private var xPos:uint;
  private var yPos:uint=50;
  private var w:uint;
  private var h:uint;
  private var heading:uint;
  private var curve:uint;
  private var planeE:Array;
  private var planeW:Array;
  private var planeN:Array;
  private var planeS:Array;
  private var sweepTime:uint=3000;
  private var ee:Boolean=false;
  private var planeFactory:PlaneFactory;
  private var sweep:Timer;
 
  public function CrowdedSky ()
  {
   planeFactory=new PlaneFactory ;
   planeE=new Array();
   planeW=new Array();
   planeN=new Array();
   planeS=new Array();
 
   upDate ();
   sweep=new Timer(sweepTime,0);
   sweep.addEventListener("timer",newPos)
   sweep.start();
  }
 
  private function makeEast ():void
  {
   yPos=80;
   heading=315;
   for (var air:uint=0; air < 50; air++)
   {
    planeE[air]=planeFactory.getIntrinsic("east");
    place ();
    planeE[air].doPlane (xPos,yPos,w,h,curve);
    addChild (planeE[air]);
    planeE[air].rotation=heading;
   }
   ee=true;
   planeE[0].x=350,planeE[0].y=700;
  }
 
  private function makeWest ():void
  {
   yPos=80;
   heading=225;
   for (var air:uint=0; air < 50; air++)
   {
    planeW[air]=planeFactory.getIntrinsic("west");
    place ();
    planeW[air].doPlane (xPos,yPos,w,h,curve);
    addChild (planeW[air]);
    planeW[air].rotation=heading;
   }
 
   planeW[0].x=700,planeW[0].y=500;
  }
 
  private function makeNorth ():void
  {
   yPos=80;
   heading=45;
   for (var air:uint=0; air < 50; air++)
   {
    planeN[air]=planeFactory.getIntrinsic("north");
    place ();
    planeN[air].doPlane (xPos,yPos,w,h,curve);
    addChild (planeN[air]);
    planeN[air].rotation=heading;
   }
 
   planeN[0].x=250,planeN[0].y=200;
  }
 
  private function makeSouth ():void
  {
   yPos=0;
   heading=135;
   for (var air:uint=0; air < 50; air++)
   {
    planeS[air]=planeFactory.getIntrinsic("south");
    place ();
    planeS[air].doPlane (xPos,yPos,w,h,curve);
    addChild (planeS[air]);
    planeS[air].rotation=heading;
   }
 
   planeS[0].x=650,planeS[0].y=150;
  }
 
  private function place ():void
  {
   //Generate extrinsic states
   xPos=Math.round(Math.random()*500);
   yPos= Math.round(Math.random()*400);
   w=10;
   h=50;
   curve=20;
  }
 
  private function cleanup ():void
  {
   removeChild (planeE[0]);
   removeChild (planeW[0]);
   removeChild (planeN[0]);
   removeChild (planeS[0]);
   planeE[0]=planeFactory.clearPlane();
  }
 
  public function newPos (e:TimerEvent):void
  {
   upDate()
  }
 
  private function upDate ():void
  {
   if (ee)
   {
    cleanup ();
   }
   makeEast ();
   makeWest ();
   makeNorth ();
   makeSouth ();
  }
 }
}

Figure 7 shows the final results. The underlying radar sweep is simply a movie clip running beneath the display.

Figure 7: Flyweight generating 200 images.Flyweight Design Pattern Reconsidered

In working through this pattern, which can be exhausting, it has a number of characteristics that are still elusive. The role of the unshared concrete flyweight is not clear, and some the examples I’ve seen may have missed the mark altogether. The use of the unshared concrete flyweight for assigning values for extrinsic states and how these are used in concert with a client with references to a shared object is not clear in most examples of the flyweight. However, it is a great pattern for understanding class relations and the nature of objects.

All in all, the Flyweight design pattern holds valuable lessons about OOP, especially some of the subtler features and certainly participant relations.With the speed of processors developing at high rates and storage now measured in gigabytes (or terabytes), whether the speed increase gained is worth the added effort is not as obvious as it once was. However, if the asymptotic performance is optimal, I see nothing wrong with looking for ways to speed up the display of large numbers of elements on a stage. I doubt that the 200 images (or even 1000) would be enough to warrant spending too much time on the Flyweight, but when the numbers being reaching 10,000 or even higher, an extra byte or two might come in handy.

In the first installment of this Flyweight Saga, I noted that the relationship between a Flyweight and Flyweight Factory class is one of aggregation. The initial example shows that the Retrieve method in the Factory class returns an instance of IFlyweight, meeting the requirement of the proper connection between the two classes. In looking at one example in Java, (even with modest Java skills), the program clearly did not have such a relationship between the Factory and Flyweight. In fact, it claimed, that an object’s extrinsic state can be shared by classes. Now, maybe that was unfortunate wording because the big feature of the Flyweight design pattern is that the Flyweight can be a shared object, but only the intrinsic state can be shared. (Maybe the author meant that extrinsic states can be shared between classes in a Flyweight design pattern, and that’s probably right but is not a key feature of the pattern.)

Anyway, after looking at several different descriptions of aggregation, including the one provided by the GoF, it’s clear that the concept is one with fuzzy borders and can slip into either general composition or acquaintance. It implies that the Flyweight Factory aggregates the Flyweight—no Flyweight, no Factory. As a result, the life of the aggregator (Flyweight Factory) depends on the life of the aggregatee (Flyweight). Like acquaintance, aggregation is implemented with references or pointers rather than defining variables of once class in another. (Apparently C++ is an exception and does set up aggregation by defining variables from the aggregatee class.)

By and large the issue has not been especially significant so far because all of the output was using trace statements, and so output was largely confined to built-in features that only work when the code is run in test mode. It’s great for debugging up to a point, but developing with trace statements that do not take into account how certain graphic elements, especially those that are accessed by extending the Sprite classes, can generate unusable structures for applications that employ graphics and other elements that require the import and extension of other classes. In this next Flyweight example, we leave the realm of trace and use the graphics property (from the Sprite class) to draw solid balls using fill methods. The ball class extends Sprite and implements the interface. That’s all fine and good, but the aggregation becomes problematic in even the simplest example. In taking the general structure from the examples examined up to this point (Parts I and II of the Flyweight Saga), we can begin to see the trouble.

Because of the need to introduce the Sprite reference somewhere in the Flyweight by extending the Sprite class the Flyweight had to be referenced indirectly through the Concrete Flyweight (FlyBall). Does this count? I don’t know, but using an interface instead of an abstract class, I could see no way in getting in the needed Sprite extension. However, I do think that the Flyweight Factory did accomplish the manufacture of a single instance with multiple copies of an object with both the red and yellow balls. The following code is the first go at this using something other than trace. However, is it indeed a true Flyweight 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
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

package
{
	//Flyweight
 
	public interface IFlyweightBall
	{
		function doCircle (xPos:uint,yPos:uint,radius:uint):void;
	}
}
 
package
{
	//Flyweight Factory
 
	public class BallFactory
	{
		protected var ballIntrinsic:Object={};
 
		public function BallFactory ()
		{
			ballIntrinsic["red"]=new FlyBall(0x990000);
			ballIntrinsic["yellow"]=new FlyBall(0xffff00);
 
		}
		public function getIntrinsic (key:String,... rest):FlyBall
		{
			switch (ballIntrinsic[key] != undefined)
			{
				case true :
					break;
				case false :
					ballIntrinsic[key]=rest[0];
					break;
			}
			return ballIntrinsic[key];
		}
	}
}
 
package
{
	//Concrete Flyweight
 
	import flash.display.Sprite;
 
	public class FlyBall extends Sprite implements IFlyweightBall
	{
		protected var fill: uint;
 
		public function FlyBall (fill:uint)
		{
			this.fill=fill;
		}
 
		public function doCircle (xPos:uint,yPos:uint,radius:uint):void
		{
			graphics.beginFill (fill);
			graphics.drawCircle (xPos,yPos,radius);
			graphics.endFill ();
		}
	}
}
 
package
{
	//Client class
	import flash.display.Sprite;
 
	public class BallClient extends Sprite
	{
 
		//Client data to provide extrinsic state details
		private var xPos;
		private var yPos;
		private var radius;
 
		public function BallClient ()
		{
			var ballFactory:BallFactory=new BallFactory;
 
			var cir1:FlyBall=ballFactory.getIntrinsic("red");
			shuffle ();
			cir1.doCircle (xPos,yPos,radius);
			addChild (cir1);
 
			var cir2:FlyBall=ballFactory.getIntrinsic("red");
			shuffle ();
			cir2.doCircle (xPos,yPos,radius);
			addChild (cir2);
 
			var cir3:FlyBall=ballFactory.getIntrinsic("yellow");
			shuffle ();
			cir3.doCircle (xPos,yPos,radius);
			addChild (cir3);
 
			var cir4:FlyBall=ballFactory.getIntrinsic("yellow");
			shuffle ();
			cir4.doCircle (xPos,yPos,radius);
			addChild (cir4);
 
			//Constructed in client
			var cir5:FlyBall=ballFactory.getIntrinsic("green",new FlyBall(0x009900));
			shuffle ();
			cir5.doCircle (xPos,yPos,radius);
			addChild (cir5);
		}
 
		private function shuffle ()
		{
			//Generate extrinsic states
			xPos=Math.round(Math.random() * 500);
			yPos=Math.round(Math.random() * 300);
			radius=Math.round(Math.random() * 100);
		}
	}
}

When this application is tested, you will see two red balls, two yellow balls and a green ball seen in Figure 1. The following line in the Flyweight Factory,

public function getIntrinsic (key:String,... rest):FlyBall

sets up the returned data as a concrete flyweight (FlyBall). In looking at the UML diagram for the Flyweight (See Part I of the Flyweight saga), the Flyweight Factory is an aggregation of the Flyweight. The aggregation relationship is one where the aggregator (Flyweight Factory) holds a reference to the aggregatee (Flyweight), but as you can see, the reference is to the Concrete Flyweight.

Abstract Class Changes Everything

The first ActionScript 3.0 Flyweight I worked was the one Jim Kremens had made for test of concept. It employed an abstract class rather than an interface, and I changed it to an interface. Now, I’ve come full circle back to the abstract class because it can be set up to inherit the needed elements of the Sprite class. This allows the Factory to establish a reference to the Flyweight rather than having to use a concrete Flyweight. The resulting application now has all of the right relationships.

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

package
{
	//Abstract class Flyweight
	import flash.display.Sprite;
 
	public class FlyweightBall extends Sprite
	{
			function doCircle (xPos:uint,yPos:uint,radius:uint):void
			{}
	}
}
 
package
{
	//Flyweight Factory
 
	public class BallFactory
	{
		protected var ballIntrinsic:Object={};
 
		public function BallFactory ()
		{
			ballIntrinsic["red"]=new FlyBall(0x990000);
			ballIntrinsic["yellow"]=new FlyBall(0xffff00);
 
		}
		public function getIntrinsic (key:String,... rest):FlyweightBall
		{
			switch (ballIntrinsic[key] != undefined)
			{
				case true :
					break;
				case false :
					ballIntrinsic[key]=rest[0];
					break;
			}
			return ballIntrinsic[key];
		}
	}
}
 
package
{
	//Concrete Flyweight
 
	public class FlyBall extends FlyweightBall
	{
		private var fill: uint;
 
		public function FlyBall (fill:uint)
		{
			this.fill=fill;
		}
 
		override function doCircle (xPos:uint,yPos:uint,radius:uint):void
		{
			graphics.beginFill (fill);
			graphics.drawCircle (xPos,yPos,radius);
			graphics.endFill ();
		}
	}
}
 
package
{
	//Client class
	import flash.display.Sprite;
 
	public class BallClient extends Sprite
	{
 
		//Client data to provide extrinsic state details
		private var xPos;
		private var yPos;
		private var radius;
 
		public function BallClient ()
		{
			var ballFactory:BallFactory=new BallFactory;
 
			var cir1:FlyweightBall=ballFactory.getIntrinsic("red");
			shuffle ();
			cir1.doCircle (xPos,yPos,radius);
			addChild (cir1);
 
			var cir2:FlyweightBall=ballFactory.getIntrinsic("red");
			shuffle ();
			cir2.doCircle (xPos,yPos,radius);
			addChild (cir2);
 
			var cir3:FlyweightBall=ballFactory.getIntrinsic("yellow");
			shuffle ();
			cir3.doCircle (xPos,yPos,radius);
			addChild (cir3);
 
			var cir4:FlyweightBall=ballFactory.getIntrinsic("yellow");
			shuffle ();
			cir4.doCircle (xPos,yPos,radius);
			addChild (cir4);
 
			//Constructed in client
			var cir5:FlyweightBall=ballFactory.getIntrinsic("green",new FlyBall(0x009900));
			shuffle ();
			cir5.doCircle (xPos,yPos,radius);
			addChild (cir5);
		}
 
		private function shuffle ()
		{
			//Generate extrinsic states
			xPos=Math.round(Math.random() * 500);
			yPos=Math.round(Math.random() * 300);
			radius=Math.round(Math.random() * 100);
		}
	}
}

The Intrinsic State

Part II of the Flyweight Saga examined extrinsic states, which are part of the key operation in the Flyweight. However, it is the intrinsic state in the concrete flyweight where we need to look now. In looking at the UML diagram, the intrinsic state is stored in the Concrete Flyweight. So, while extending the Flyweight and implementing the key operation, we need to add an intrinsic state. In this case, the intrinsic case is placed as a parameter within the concrete flyweight constructor. The following lines are the crux of the intrinsic state:

protected var fill: uint;
public function FlyBall (fill:uint)
{
this.fill=fill;
}

The protected variable fill is the key here. As part of the constructor, the fill value is stored in the concrete flyweight. Then, when the operation calls the extrinsic parameters, the fill variable provides the color code for the concrete flyweight’s implementation of the instance. So, once the ball instance is created in the factory participant (BallFactory), the intrinsic value remains constant no matter what the values of the extrinsic values passed in the concrete flyweight method. As a result, it is possible to make multiple instances of the red and yellow balls using the intrinsic color that was in the associative array (ballIntrinsic). Thus, the line,

ballIntrinsic["red"]=new FlyBall(0x990000);

creates a “red” instance providing the fill color value in the construction parameter (0x990000). If the same key is called from the client, the getIntrinsic function checks to see if it exists or not. If it does, it simply returns the instance with the included color value stored as an intrinsic state. The extrinsic states, which include the radius, and x and y positions, simply re-use the existing red ball and change only the extrinsic states. (See Flyweight Saga Part II.)

Keep in mind that this process is a matter of working out the specific sense of a Flyweight pattern more than it is to show the optimum example. In going over some Flyweight materials from MIT, they suggested having a grasp on other, simpler patterns like the Observer and even MVC before tackling the Flyweight. This was both comforting and worrisome!

Extrinsic State Parameter

To get back on track (somewhat), this new Flyweight includes a parameter for extrinsic states in the Flyweight interface. Because the state is extrinsic, it changes with the Flyweights context. As discussed briefly in Part I of this saga, the extrinsic state changes with the context while the intrinsic state does not. Thus, the extrinsic state is not shareable (a shared object) and the intrinsic is. A concrete class can be sharable or not, but it cannot be if it does not store the intrinsic state. However, both sharable and non-sharable concrete Flyweights can exist. The following summary might be helpful.
Extrinsic state

Cannot be shared
Depends on flyweight’s context
Client is responsible for supplying extrinsic state when needed

Intrinsic state

Can be shared
Stored (inherent) in the flyweight
Does not depend flyweight’s context

Adding a Numeric State Changer
To get started this first new Flyweight does nothing more than add an extrinsic parameter to the existing Flyweight and adds a few new wrinkles. The Flyweight interface key operation includes a numeric (uint) parameter used as a state change indicator. The intrinsic characteristic of the concrete Flyweight, FlyButton, is nothing more than the part of the trace statement indicating “Fly button #.” The extrinsic value (state) is the extrinsic variable that is incremented with each use.

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

package
{
	//Interface
	public interface IFlyweight
	{
		function build (extrinsic:uint):void;
	}
}
 
////////
 
package
{
	//Factory
	public class Factory
	{
		protected var objects:Object = {};
 
		public function Factory ()
		{
			objects["nav"] = new FlyButton();
			objects["send"] = new FlyButton();
			objects["about"] = 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];
		}
	}
}
 
////////
 
package
{
	//Concrete Flyweight (shared)
	public class FlyButton implements IFlyweight
	{
		public function FlyButton ()
		{
		}
		public function build (extrinsic:uint):void
		{
			trace ("Fly button #" + extrinsic );
		}
	}
}
 
////////
 
package  {
 
	import flash.display.Sprite;
 
	//Client class
	public class ButtonMaker extends Sprite {
 
		private var extrinsic:uint;
 
		public function ButtonMaker() {
 
			extrinsic=1;
 
			var factory:Factory  = new Factory();
 
			var nav:IFlyweight = factory.Retrieve("nav"); //"Nav" created in Factory
			nav.build(extrinsic++);
 
			var launch:IFlyweight = factory.Retrieve("send"); //"Send" created in Factory
			launch.build(extrinsic++);
 
			var about:IFlyweight = factory.Retrieve("about"); //"About " created in Factory
			about.build(extrinsic++);
 
			var playit:IFlyweight = factory.Retrieve ("play", new FlyButton());
			playit.build(extrinsic++);
		}
 
	}
}

That seems to work fine, and most of the buttons were generated in the Factory, but one is created in the client. Given the nature of the design, that’s fine. You will see the following output:

1
2
3
4

Fly button #1
Fly button #2
Fly button #3
Fly button #4

The Adding Something a Button Could Use
Keeping in mind that we’re looking for a better way to generate buttons to be placed on the page, we will need to add parameters to the existing interface. The needs are simple and identical for each button: a name, an x position, and a y position. So, all that’s necessary is to add parameters for those values and then add something to the client that generates those values. This next example gets us closer to that goal.

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

package
{
	//Parameters for button label and x and y values
	public interface IFlyweight
	{
		function build (bname:String,xpos:uint,ypos:uint):void;
	}
}
 
////////
 
package
{
	//Flyweight Factory
	public class Factory
	{
		protected var objects:Object = {};
 
		public function Factory ()
		{
			objects["nav"] = new FlyButton();
			objects["send"] = new FlyButton();
			objects["about"] = 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];
		}
	}
}
 
////////
 
package
{
	//Concrete Flyweight
	public class FlyButton implements IFlyweight
	{
		public function FlyButton ()
		{
		}
		public function build (bname:String,xpos:uint,ypos:uint):void
		{
			trace ("Fly button " + bname+ " is located at " + xpos +","+ypos);
		}
	}
}
 
////////
 
package  {
 
	import flash.display.Sprite;
 
	//Client class
	public class NamePlace extends Sprite {
 
		//Client data to provide extrinsic state details
		private var bnamesA:Array=["Play","About Us","Send","Navigation"];
		private var xposA:Array=[20,20,20,20];
		private var yposA:Array=[20,40,60,80]
 
		public function NamePlace() {
 
			var factory:Factory  = new Factory();
 
			var nav:IFlyweight = factory.Retrieve("nav"); //"Nav" already exists
			nav.build(bnamesA.pop(),xposA.pop(),yposA.pop());
 
			var launch:IFlyweight = factory.Retrieve("send"); //"Send" already exists
			launch.build(bnamesA.pop(),xposA.pop(),yposA.pop());
 
			var about:IFlyweight = factory.Retrieve("about"); //"About " already exists
			about.build(bnamesA.pop(),xposA.pop(),yposA.pop());
 
			var playit:IFlyweight = factory.Retrieve ("play", new FlyButton());
			playit.build(bnamesA.pop(),xposA.pop(),yposA.pop());
		}
 
	}
}

This time the output is going to look a lot more like what we need for the buttons. The name of the button, and it’s x,y location all appear in the output as the following shows:

1
2
3
4

Fly button Navigation is located at 20,80
Fly button Send is located at 20,60
Fly button About Us is located at 20,40
Fly button Play is located at 20,20

Going back to the comments made on this blog, it’s probably wise to create all of the new buttons in the Factory. Also, we need to take a closer look at what is going on with intrinsic values in the FlyButton class. However, it’s creeping along, and in doing so gets us closer to the goal.

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.