In describing the Prototype design pattern, the Gang of Four indicate that in the collaborations, the client asks a prototype to clone itself. (Go clone yourself!) As innocuous as that sounds, it turns out to be more than a little work, and the pattern, as GoF indicates, is tricky and easy to get wrong. With ActionScript 3.0, my response is, “…you have no idea!”

In a couple of earlier articles relating to the Prototype design pattern in this blog (ActionScript 3.0 Clone and ActionScript 3.0 Recursive Excursion) we looked at some of the issues relating to key elements of the Prototype design pattern, and if you’re thinking of using the Prototype pattern, you might want to take a look at them and some of the comments that readers have made. I’d prefer not to re-hash them here so that we can focus on the design pattern and not its components or underlying processes that we’ve already discussed. So to get started, let’s take a look at the Prototype class diagram in Figure 1:

Figure 1: Prototype Design Pattern

Because the pattern includes a Client class, you can see right away where the client connects to the other participants in the pattern and something about the nature of the relationship. The key here is that the client holds an object reference to the Prototype class. So the client is going to have some kind of Prototype reference.

The second key element is the recursive nature of the cloning process. Each concrete class clones itself with a method inherited from the Prototype class. The problem, of course, is where are we going to get a cloning method and how can it be implemented recursively? One solution is simply to build an abstract class that includes a cloning process and then make the Prototype class a subclass to pass on the clone method. That’s what I did, but by keeping the CloneMachine class abstract, no instance of the CloneMachine class could be instantiated in the Prototype class. Nevertheless, I now had access to a cloning method. In some respects that sounds like strong-arming a solution, but I don’t think so. The Java solutions implemented Clonable in the Prototype class and C# solutions used MemberwiseClone and [Serializable] in their Prototype class (among other solutions). The result is that the clone method doClone(obj) from the inherited class is available for creating a clone method in the Prototype class. In the end, I came up with the design shown in Figure 2:

Figure 2: ActionScript Prototype Pattern

I cannot claim originality in subclassing one abstract class with another. GoF have a few examples, such as an application on page 224 where a Widget class is a subclass of a HelpHandler class—both are abstract classes.

The CloneMachine and Prototype

The first step is to build the class containing the clone method. As described in the previous article on cloning, this methods uses the ByteArray.

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

/* Do not implement: Treat as Abstract Class */
/* Utility class : Cloning method*/
package
{
	import flash.utils.ByteArray;
 
	public class CloneMachine
	{
		private var cloneWork:ByteArray;
 
		public function doClone(source:Object):*
		{
			cloneWork = new ByteArray();
			cloneWork.writeObject(source);
			cloneWork.position = 0;
			return (cloneWork.readObject());
		}
	}
}

Now that the clone method is available, it will be used to generate the abstract clone method in the Prototype. This makes it a little easier to use the try..catch..finally statement to check for errors and neatly return the cloned object.

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

/* Prototype class */
/* Do not implement: Treat as Abstract Class */
package
{
	import flash.errors.IllegalOperationError;
 
	public class Prototype extends CloneMachine
	{
		public var breed:String;
		public var description:String;
		public var unique:String;
 
		public function clone(obj:Object):Object
		{
			var clone:Object = null;
			try
			{
				clone = super.doClone(obj);
			}
			catch (e:ArgumentError)
			{
				trace(e);
			}
			finally
			{
				return clone;
			}
		}
		public function getDescription():String
		{
			return description;
		}
		public function getBreed():String
		{
			return breed;
		}
		public function getUnique():String
		{
			return unique;
		}
		public function setDescription(string:String):void
		{
			description = string;
		}
		public function setBreed(string:String):void
		{
			breed = string;
		}
 
		public function setUnique(string:String):void
		{
			unique = string;
		}
	}
}

The clone method is set up by a simple reference to the parent method (clone = super.doClone(obj);). Placed in a try..catch..finally statement, it catches any errors in cloning the object. Otherwise, it returns a clone. Several different get/set functions provide a set of properties for the prototype. The last property, unique is overridden in the two concrete Prototype classes for the purpose of example.

Concrete Prototypes

Keeping everything at a minimal level only two concrete prototypes are introduced, Dog and Cat as shown in the following two classes.

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

// ActionScript file
//Concrete Prototype: Dog
package
{
	public class Dog extends Prototype
	{
		public var doggyTreat:String;
 
		 override public function getUnique():String
		{
			return doggyTreat;
		}
		override public function setUnique(yum:String):void
		{
			doggyTreat=yum;
		}
	}
}
 
/ ActionScript file
//Concrete Prototype: Cat
package
{
	public class Cat extends Prototype
	{
		public var kittyToy:String;
 
		 override public function getUnique():String
		{
			return kittyToy;
		}
		override public function setUnique(playful:String):void
		{
			kittyToy=playful;
		}
	}
}

As you can see, the two concrete classes do nothing more than provide a single setter and getter pair to illustrate that they are different and yet part of the Prototype.

The Client Makes a Clone

The final step in this minimalist Prototype pattern is to build the Client. The client holds a reference to the Prototype class by creating an instance of the Dog and Cat classes, typing both as a Prototype. Then, using a recursive clone, each instance creates a clone of itself.

Lastly, the clone objects are then traced to view the property values of the cloned objects. This last step is to be sure that the cloned objects actually have the properties and property values of the originals.

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

package
{
	//Client
	import flash.display.Sprite;
 
	public class Client extends Sprite
	{
		private var tDog:Prototype;
		private var cDog:Object;
		private var tCat:Prototype;
		private var cCat:Object;
 
		public function Client()
		{
			tDog = new Dog();
			tDog.setDescription("Big compulsive brown, black and tan");
			tDog.setUnique("Bacon");
			tDog.setBreed("Greater Swiss Mountain Dog");
 
			cDog = tDog.clone(tDog);
			trace(cDog.breed);
			trace(cDog.description);
			trace("Treat: "+cDog.doggyTreat +"\n");
 
			tCat = new Cat  ;
			tCat.setDescription("Sleek, independent, black and tan");
			tCat.setUnique("catnip");
			tCat.setBreed("Siamese");
 
			cCat = tCat.clone(tCat);
			trace(cCat.breed);
			trace(cCat.description);
			trace("Favorite toy: "+ cCat.kittyToy);
		}
	}
}

You will see the following output when you test it:

Greater Swiss Mountain Dog
Big compulsive brown, black and tan
Treat: Bacon

Siamese
Sleek, independent, black and tan
Favorite toy: catnip


Before looking at the uses of the Prototype, you should be aware that the cloned objects do not have the methods of the original. For example, the tDog instance can use all of the methods of both the Prototype and Dog classes. However, the cloned instance, cDog cannot use any of them. We had to have a public property declared in the Prototype and concrete Prototype classes to bring out the properties and their values in the clones. That is, rather than being able to use the getter methods, we had to refer directly to the properties. For example, we had to use

     cCat.kittyToy;

instead of,

     cCat. getUnique();

That’s a little mystery I’d like to solve.

Uses of the Prototype

As is often the case in looking at design patterns, the best use case I found was in Head First Design Patterns. The Freemans suggest a monster maker where prototypes of monsters would be used to generate clones in a game where monsters were routinely dispatched and re-generated. Cloning would be simpler and less expensive than recreating new monsters in a rapidly changing environment. The idea is to make a prototypical instance and then clone it whenever the system requires a new one. This is especially useful when the classes to instantiate are done so at run-time. In a an environment where any combination of creations are required at unknown points, the Prototype is one pattern to consider.

Another Loop?

In some respects, recursion is just another looping structure, but programmers tend to think about them differently, and I thought I’d see what I could find from some of the big brains at OOPSLA. I talked with Dr. Axel Schreiner about recursion and got all I could ever imagine anyone would want to about them. However, like many, he considered recursion to be a loop structure and didn’t seem to be particularly excited whether loops or recursive structures were employed. For Axel, recursion and looping were a matter of looking at repeated actions in different ways.

Defined, a recursion is a method (or function) that can call itself. That doesn’t sound like a loop, but it does have a repeating element in that a recursive function repeats a process by the simple fact of calling itself. The most common examples of recursion is a factorial, but Fibonacci sequences and Towers of Hanoi are other common examples used to illustrate recursion. Since Fibonacci sequences are one of those just plain cool math structures, I thought I’d start with a Fibonacci sequence.

A Fibonacci Example

A Fibonacci sequence is one where each number in a sequence is made up of the sum of the previous two in the sequence. The sequence begins with 0 and 1:

0 1 1 2 3 5 8 13 21

Rather than using a loop to generate the sequence, the recursive function in the following example takes a parameter (r) and returns the next value in the sequence after r. The following class calls the recursive function via a trace() statement. (I was using Flex, but Flash works fine for the same function.)

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

/*Fibonacci  generated in a recursive function*/
package
{
	import flash.display.Sprite;
 
	public class FibRecursion extends Sprite
	{
		public function FibRecursion()
		{
			trace(fibo(8));
		}
 
		private function fibo(r:uint):uint
		{
			if(r==0)
			{
				return 0;
			}
			else if (r==1)
			{
				return 1;
			}
			else
			{
				return fibo(r-1) + fibo(r-2);
			}
		}
	}
}

The recursion occurs in the third return statement. That is, part of the fibo() function calls itself. As you will see, the output is,

21

The question is, what’s going on inside the cursive function?

A Simple Recursive Function

While the Fibonacci is fun and shows that a recursive function is possible in ActionScript 3.0, it doesn’t really show too much about the inner workings of the recursive method. So I put together a simple class with a recursive structure.

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

// Simple Recursion
package
{
	import flash.display.Sprite;
 
	public class Simple extends Sprite
	{
		public function Simple()
		{
			trace("End value: "+recursive(10));
		}
 
		private function recursive(n:uint):uint
		{
			if(n<=1)
				return n +100;
			else
				trace("Trace:"+recursive(n-1));
				return n;
		}
	}
}

Keeping in mind that every trace() of the function fires the function, we need to be judicious in where we place our trace statements. In the recursive function, recursively named, recursive, the return in the first condition adds 100 to values of less than or equal to one. (I could not concatenate a string because the return must be an unsigned integer.) The class generates the following output:

As you can see, the first return value is 1 plus 100. After the first value, the next is 2, and so forth until 9, and then the terminal output occurs as 10, the value of the initial function argument.

This little excursion into recursion is another side trip on the way to a ground up Prototype design pattern that I’m still working on. I’ve looked at a lot of examples from different languages; unfortunately, they have certain built-in features for cloning or abstract classes lacking in ActionScript 3.0—or ECMAScript 264, ref 4. However, like all of the other patterns, eventually this one will get wrestled to the ground.

The next design pattern I plan to tackle in ActionScript 3.0 is the Prototype Design Pattern. Getting started I ran into the clone() method in other languages like C#. As usual, that wasn’t much help. To my surprise, I found that several classes in ActionScript 3.0 have a clone() method such as the Rectangle class. However, while perfectly functional, cloning a rectangle with origins in the flash.geom namespace isn’t exactly what I had hoped for. (There’s no clone() method in the Shape class where I could make lots of clones of rectangle shapes I could put on the stage.) What I wanted was a way to clone objects.

Borrowing from Java

Buried in the Adobe ActionScript 3.0 Live Docs is a little note about cloning arrays. (see http://livedocs.adobe.com/flex/3/html/10_Lists_of_data_6.html) Using a method commonly found in Java programs, the note indicates that a deep copy clone is possible using this method. One can use concat() or slice() with no arguments to make a shallow copy. In most cases, GoF note that shallow copies will work fine, but for more complex structures a deep copy is required.

The docs list the key method as the following:

1
2
3
4
5
6
7
8
9

import flash.utils.ByteArray;
 
function clone(source:Object):*
{
    var myBA:ByteArray = new ByteArray();
    myBA.writeObject(source);
    myBA.position = 0;
    return(myBA.readObject());
}

That’s a nice little piece of code and simple to understand. The clone() method creates a ByteArray that writes the object (an array) and then returns it by reading the object it just wrote. Moreover, it’s a deep copy and as such a true clone in that all of the parts are delivered and not just pointers.

A Cloning Class

Cloning an array is fine, and I even added a note in Live Docs first asking for an example and then provided one. (I’m not trying to befuddle those who screen comments on Live Docs—it’s just an added bonus.) What I really want to do is to clone an object, and since an array is an object, it seemed to be an easy enough task. So I took the basic algorithm and made it the key method of a Clone class. Here’s the code:

Clone.as

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.utils.ByteArray;
	import flash.display.Sprite;
 
	public class Clone extends Sprite
	{
		private var cloneWork:ByteArray;
 
		public function Clone()
		{
			//Constructor
		}
 
		public function doClone(source:Object):*
		{
			cloneWork=new ByteArray();
			cloneWork.writeObject(source);
			cloneWork.position = 0;
			return (cloneWork.readObject());
		}
	}
}

Next, I created an object with lots of properties of different types—string, number and Boolean. Then, I tried cloning it, and it seemed to work. The following listing shows the client class that used the clone method—doClone() from the Clone class:

ObjectClone.as

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

package
{
	import flash.display.Sprite;
 
	public class ObjectClone extends Sprite
	{
		private var clone:Clone;
		private var webLanguages:Object;
		private var moreWeb:Object;
 
		public function ObjectClone()
		{
			webLanguages={};
			webLanguages.flex="ActionScript 3.0";
			webLanguages.dotNet="C#";
			webLanguages.php="PHP";
			webLanguages.inHtml="JavaScript";
			webLanguages.bandWidth=2500000;
			webLanguages.usesFMS=true;
 
			for (var w:* in webLanguages)
			{
				trace("Property "+w+"="+webLanguages[w]);
			}
 
			trace("------------------------");
 
			moreWeb=new Object();
			clone=new Clone();
			moreWeb = clone.doClone(webLanguages);
 
			for (var k:* in moreWeb)
			{
				trace("Property "+k+"="+moreWeb[k]);
			}
		}
	}
}

The following output shows that the cloned object has all of the properties and values of the original:

Property flex=ActionScript 3.0
Property dotNet=C#
Property usesFMS=true
Property php=PHP
Property inHtml=JavaScript
Property bandWidth=2500000
------------------------
Property flex=ActionScript 3.0
Property dotNet=C#
Property bandWidth=2500000
Property usesFMS=true
Property php=PHP
Property inHtml=JavaScript


The mystery is why the output is ordered the way it is. (If anyone knows, please send a comment.) All of the pieces to the objects are there in the clone, and they reflect the correct values of the original. The clone may seem a bit Frankenstein-ish, since the parts are in a different order, but the original seemed to move the parts around as well; so I’m not too concerned.

Next Stop: Prototype Design Pattern

Now that I have a working clone method for cloning objects, the next step will be working it into the Prototype pattern. The issue of serialization has not been broached here, but it is a topic I hope to take up in discussing the Prototype. Also, there’s not a lot of difference between an Object as used in this example and an associative array (ActionScript’s hash table equivalent). So, I may make it look more like an associative array rather than a plain vanilla object even though I like the idea of an object better. Also, I believe that using the Prototype Design Pattern beyond a simple example may require more work in the clone department to clone more sophisticated objects like MovieClips and Components.

Comments encouraged!!