It's my first time too!

In learning OOP and Design Patterns, what you’re learning is a set of principles with associated programming patterns. The Template Method is a valuable starting place because it is used to illustrate the OOP/DP principle called The Hollywood Principle. Be sure to go over the more detailed post on the Hollywood Principle, but for here, you just need to become familiar with the idea that higher level components (like parent classes and interfaces) should call lower level components (like concrete classes), but lower level components, should not call higher level components. The principle is called Hollywood, because the casting director tells the budding actor,

Don’t call us, we’ll call you.

The parent class tells the child class the same thing.

Class Diagram

In order to understand a class diagram, you need to understand class relations. If you understand how to work with an UML, you’re ahead of the game; however, if not, we’re prepared a 4-part series to help you understand the UML and the whole concept of relations between pattern participants. Figure 1 shows the class diagram for the Template Method:

Figure 1: Template Method Class Diagram

After you’ve studied the class diagram for a bit, you can see that it’s made up of one abstract class (all italicized bold lettering indicates an abstract class or interface), and one subclass. One of the operations in the abstract class is concrete (Template Method) and the others are abstract (primitive operations). The abstract methods are italicized.

The template method is made up of the steps in an algorithm, some of which are abstract and some that can be concrete. The template method orders the steps in the algorithm, but the concrete subclass provides concrete implementations of the abstract methods using override. The following two buttons provide a preview of Play and all of the files are available for download:

Abstract Classes and Primitives

One of the more poorly defined concepts in computer programming is that of primitives. Usually when we think of primitives, we think of basic data types like numbers, strings and Booleans. However, the Gang of Four parenthetically note that primitive operations are nothing more than abstract methods. For example, the following is an abstract operation (or method):

1
2
3
4
5

protected function DoUI():Sprite
{
    throw new IllegalOperationError("Must override");
    return null;
}

Because ActionScript 3.0 has no abstract classes or methods, you have insure that the abstract methods will not be directly instantiated, and one way to do that is to add the illegal operation line. Further to have the proper signature, the method must include some kind of return statement, and a null value does the trick. In the concrete implementation, each primitive operation is overridden and provided concrete operations.

Within the abstract class, you can have both concrete and abstract methods. One of the advantages of an abstract class (compared with an interface) is that abstract classes can have some concrete methods. For example the following template method uses two primitive operations and a concrete one. It’s just is to order the steps of the algorithm, which in this case has three:

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

...abstract class..
 
public function templateMethod()
{
	DoLogo();
	DoUI();
	DoInfo();
}
 
protected function DoUI():Sprite
{
	throw new IllegalOperationError("Must override");
	return null;
}
 
protected function DoInfo():TextField
{
	throw new IllegalOperationError("Must override");
	return null;
}
 
protected function DoLogo():Sprite
{
	var logo:Sprite=new Sprite();
	return logo;
}
 
...abstract class

So let’s stop a second and consider why and how we’d use a Template Method design based on the following:

1. An abstract class
2. A method that orders the steps in an algorithm
3. At least one abstract method that is overridden by a concrete class that implements the abstract class.

The abstract class affords the programmer flexibility when similar algorithms are used again and again but with slightly different implementations. For example, you may find yourself using a “page algorithm.” The page algorithm loads your logo, creates a UI and then creates content. The logo loading part is going to be the same as you use your logo over and over again. However, the UI and content can vary in several different ways. For that, you need flexibility.

Page Arranger

To get started on the algorithm for a page arranger, we’ll start with the abstract class which is named IServices. One convention you will find in OOP is using an “I” prefacing all Interfaces. I like to do the same thing with abstract classes because other than the concrete properties and methods, you should think of them as a type of interface. (If you’re just getting started in OOP and Design Patterns, you might want to check out Beginners Start to see where the files go in Flash and Flash Builder.)

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

package
{
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
	import flash.net.URLRequest;
	import flash.display.Loader;
 
	//Abstract class. Do not instantiate directly
	//Extend the class for concrete child classes
 
	public class IServices extends Sprite;
	{
 
		private var logoPix:URLRequest=new URLRequest("logo.swf");
		protected var uiPix:URLRequest;
		protected var infoPix:URLRequest;
		private var logoLoader:Loader=new Loader();
		protected var uiLoader:Loader=new Loader();
		protected var infoLoader:Loader=new Loader();
		private var page:Sprite=new Sprite();
		private var logoSprite:Sprite=new Sprite();
		protected var uiSprite:Sprite=new Sprite();
		protected var infoSprite:Sprite=new Sprite();
 
		public function templateMethod():Sprite
		{
			page.addChild(DoLogo());
			page.addChild(DoUI());
			page.addChild(DoInfo());
			return page;
		}
 
		protected function DoUI():Sprite
		{
			throw new IllegalOperationError("Must override");
			return null;
		}
 
		protected function DoInfo():Sprite
		{
			throw new IllegalOperationError("Must override");
			return null;
		}
 
		protected function DoLogo():Sprite
		{
			logoLoader=new Loader();
			logoLoader.x=0;
			logoLoader.y=0;
			logoLoader.load(logoPix);
			logoSprite.addChild(logoLoader);
			return logoSprite;
		}
	}
}

In the abstract class IServices, you can see two abstract methods (primitive operations), and two other methods—DoLogo and templateMethod. The DoLogo is going to be the same assuming that the company keeps the same logo; so you might as well set it up and let the child classes reuse it when they extend the abstract class. However, the UI and information may change, and so both of the methods for what they may include are left up to the concrete implementation.

Next, enter the concrete implementation of the abstract class. In the following you will see that both of the abstract methods are not implemented.

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

package
{
	import flash.display.Sprite;
	import flash.net.URLRequest;
	import flash.display.Loader;
 
	public class ConcreteService extends IServices
	{
		override protected function DoUI():Sprite
		{
			uiPix=new URLRequest("UI.swf");
			uiLoader=new Loader();
			uiLoader.x=0;
			uiLoader.y=110;
			uiLoader.load(uiPix);
			uiSprite.addChild(uiLoader);
			return uiSprite;
		}
 
		override protected function DoInfo():Sprite
		{
			infoPix=new URLRequest("info.swf");
			infoLoader=new Loader();
			infoLoader.x=150;
			infoLoader.y=110;
			infoLoader.load(infoPix);
			infoSprite.addChild(infoLoader);
			return infoSprite;
		}
	}
}

Keeping in mind that you never implement an abstract class, but you want to program to the abstract class (think interface), you will need a client class to request the use of the concrete implementation. However, by declaring the requesting instantiation through the abstract class, you can keep the binding loose. So the variable tm is typed to IServices but instantiates ConcreteService.

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

package
{
	import flash.display.Sprite;
	public class Client extends Sprite
	{
		private var tm:IServices=new ConcreteService();
		public function Client()
		{
			addChild(tm.templateMethod());
		}
	}
}

As you can see, there’s not much work for the Client. All it has to do is to use addChild to place the returned Sprite object to the display area. The templateMethod() operation is wholly inherited from the IServices class, but at the same time the ConcreteService class allows flexibility of what goes into the DoInfo and DoUI methods.

Play around with this example. The best way is to create some .swf files that you can use instead of the ones provided for download on this post. You’ll begin to see how flexible this design pattern is and how easy it is to use.

The Template Method pattern leads to an inversion of control known as the “Hollywood Principle,….” (1996)

As we know, Dependency Inversion is better understood as Abstraction Dependency—both higher and lower level components come to depend on abstractions. If we think depend on abstractions we have no need to even consider inversion. Doing so only confuses the issue. So, if we examine the Hollywood Principle, let’s do so in terms of what it does in its own right—what is its focus?

The Hollywood Principle holds that higher level components should call lower level components, but lower level components should not call higher level components.

So, if we take that focus of the Hollywood Principle we can better discuss its unique features. Is it related to the other principles of OOP? Of course it is, but let’s just focus on the point it makes.

Think Responsibility not Flow of Control

I’ve spent way too much time thinking about flow of control while I should have been thinking about what responsibility each component has. John Vlissides brings up this point in discussing the Hollywood Principle and the Template Method. So let’s just take a second to examine the difference between flow of control and responsibility.

In a traditional flow chart, you can see that the focal point is flow of control and not component responsibility. Figure 1 shows a typical flow chart:

Figure 1: Flow charts focus on the flow of control

Are flow charts really that helpful in OOP? They certainly help to outline different procedures and the sequence of those procedures; however, they were developed for sequential programming and later adopted for procedural programming once it was introduced. By using flow charts, I believe that a developer lays the foundation for sequential or procedural structures.

So, no, we don’t need no stinkin’ flow charts.

Now, let’s switch to a very different way of looking at programming. Rather than looking at a class diagram, an object diagram or an interaction diagram (those found in GoF), let’s take a look at a statechart. Figure 2 shows a statechart representing lighting in a darkroom used for developing film.

Figure 2: Statecharts focus on states as objects and the transition between states.

Imagine walking into a darkroom and flipping on the light switch. The transition from one state to another is through a trigger. In this case, the trigger is moving the switch from the down to up position. The room lights up. The initial state is one where all lights are off. (Statecharts represent the initial state with a large black dot.) When you get ready to make prints, you will need to turn on a safelight (a red light is used in the example) so that you can see what you’re doing while developing the prints. Full light would ruin the prints in the developing phase; so the white lights must be turned off. Once the developing is complete, you can turn on the white lights again. You can leave on the safelight, but you’ll probably want to turn it off to save both the safelight bulb and electricity.

The thinking is quite different here than with a flowchart. Each state is an object and some kind of event (trigger) moves from one object (state) to another. A state as an object moves the focus from the flow of control to the makeup of the state. The flow is relegated to an event (trigger) that makes transitions from one set of responsibilities (state object) to another.

Now we can look at a class diagram and understand it wholly apart from a flowchart. In Figure 3, we see no flow of control at all, but only responsibilities in the Template Method Design Pattern.

Figure 3: Class diagrams show object responsibilities

The Template Method (as a design pattern) is different from the template method (an operation). As an operation, the template method simply orders the primitive operations. The actual operations are left to the implementations—concrete classes. The focal point is on organizing primitive operations. Any number of concrete classes can be derived from the abstract class, and their primitive operations can be whatever the developer wants as long as they maintain the abstract class’s interface. John Vlissides notes,

Therefore when you define a new subclass of Node (Abstract class), you have to think not in terms of control flow but responsibility—the operations you must override, those you might override, and others you mustn’t override. Structuring your operations as template methods makes these responsibilities more explicit.

The steps of an algorithm vary with the Template Method Design Pattern.

A concrete but simple example of a Template Method would help better understand what Vlissides is talking about.

You Got the Call!

The Template Method Design Pattern is one of the simplest yet most useful and intriguing of all design patterns. (For full details for using it with ActionScript 3.0, see Chapter 9 of our book.) Here, we will look at it in terms of how it reveals the Hollywood Principle, while keeping in mind that the principle itself is a general one that applies to other design patterns and OOP programming in general. I made two versions that you can download; one with the Vector class (requires Flash CS4 or newer or Flex Builder version that supports Vectors) and the other with the Array class (ActionScript 3.0.)

As you can see in Figure 3, the design pattern is very simple. This particular template method employs three graphics. One is a large tan rectangle to be used as a backdrop, and the other two are a red circle and a brown rectangle. The circle and the rectangle overlap, with one or the other on top, depending on what the template method (an operation in the AbstractTM class) decides. The order of the shape objects to be displayed can be changed in the template method. In Figure 4, the image on the left is the initial rendering, and the image on the right shows what happens when the algorithm is reordered.

Figure 4: Template method determines sequence of an algorithm

Essentially, all that’s happening is that the vector (or array) element order is changed. The Client uses the pop() method to pull the elements out; so, it first pulls out the tan background and places it in the display list. Then, depending on the order of the steps in the template method, it places the red circle or brown rectangle on top of the tan rectangle and overlapping one another.

Setting Up the Order

Basically, the Template Method establishes the sequence of an algorithm. So the first thing to do is to create the abstract class that will hold the template method that orders the sequence of operations.

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

//Abstract Template Method
package
{
	import flash.display.Shape;
	//Abstract class do not instantiate
	public class AbstractTM
	{
		private var tmShape=new Shape();
		private var tmVector:Vector.<shape>=new Vector.<shape>();
 
		/*Note: Use Array instead of Vector
		with Flash CS3 or version of Flex
		that does not support Vector class */
 
		public final function templateMethod():Vector.<shape>
		{
			tmVector.push(roundShape());
			tmVector.push(recShape());
			tmVector.push(baseShape());
			return (tmVector);
		}
 
		protected function roundShape():Shape
		{
			//Work out details in
			//Concrete class
			return tmShape;
		}
 
		protected function recShape():Shape
		{
			//Work out details in
			//Concrete class
			return tmShape;
		}
 
		private function baseShape():Shape
		{
			tmShape.graphics.beginFill(0xF6E497,1 );
			tmShape.graphics.drawRect(100,50,200,200);
			tmShape.graphics.endFill();
			return tmShape;
		}
	}
}

Notice that the templateMethod() operation simply takes the three functions (that return shapes) and pushes them into the Vector (or Array) object. The function is locked using the final access statement so that it cannot be overridden. Depending on the order, they will be popped out with different consequences. Two of the operations are protected and one is private. The private operation is the one you don’t want to change both in terms of its position in the Vector and its characteristics. It serves as the background for any other Shape objects you may later want to place on top of it.

Next, build a concrete class that extends the abstract class containing the template method. Basically, this class provides the algorithms for creating different shapes. Each of the two protected functions are overridden and filled with code that creates a shape and returns it.

//Concrete Class

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

package
{
	import flash.display.Shape;
 
	public class ConcreteTM extends AbstractTM
	{
		override protected function roundShape():Shape
		{
			var tmShape=new Shape();
			tmShape.graphics.beginFill(0xB9121B,1 );
			tmShape.graphics.drawCircle(175,125,50);
			tmShape.graphics.endFill();
			return tmShape;
		}
 
		override protected function recShape():Shape
		{
			var tmShape=new Shape();
			tmShape.graphics.beginFill(0x4C1B1B,1 );
			tmShape.graphics.drawRect(175,125,100,100);
			tmShape.graphics.endFill();
			return tmShape;
		}
	}
}

At this point we need to consider what has been created because the entire design pattern is made up solely of the AbstractTM and ConcreteTM. Had we wanted, we could have added more concrete classes that use the same template method, but for now, this simple example works fine to illustrate the Hollywoood Principle. Basically, the abstract class has the code to generate a background shape and then orders the three functions in any way required by the task in the templateMethod.

In reviewing John Vlissides comment that we should not concern ourselves with the flow of control, but instead make decisions about what must and must not be overridden in our design. Now we’re thinking about the responsibilities of the objects instead of the flow of control.

Finally, we need to make make that call!. Using the Client, we type an object as the abstract class and then instantiate the concrete class. When the Client makes a request, it does so through the AbstractTM class, and then to the ConcreteTM class. As you will see in the following code, the call is make through the templateMethod() to the specific shapes, and you can clearly see that no reference at all is made to either of the concrete methods in the ConcreteTM class.

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

package
{
	import flash.display.Sprite;
	import flash.display.Shape;
 
	public class Client extends Sprite
	{
		private var shapeTM:AbstractTM = new ConcreteTM();
		private var tmShape:Shape=new Shape();
		private var tmVector:Vector.<shape>;
 
		/*Note: Use Array instead of Vector
		with Flash CS3 or version of Flex
		that does not support Vector class */
 
		public function Client()
		{
			tmVector = shapeTM.templateMethod();
			for (var vShape:uint=0; vShape<3; vShape++)
			{
				tmShape = tmVector.pop();
				addChild(tmShape);
			}
		}
	}
}

Because the example returns the shapes in an vector/array, you have lots of options. As in the example, you can let the template method order them into the display list, but alternatively you can pass them from the vector/array elements

Into the Lunch Bucket

Not only is the Hollywood principle a good one to take to work and use, you can throw in the Template Method Design Pattern to keep it company. Both are easy to remember, simple to create and very practical. Further, you have a lot of flexibility. As a general rule, I like typed vectors, and so I tend to use the Vector class wherever possible. However, if you use the Array class, you can mix in different types of objects. For example, you might want to set up a template method that uses an array to display text objects for references for graphic object. So you could have a caption or heading and then use it to display a package of a fully described graphic.

In addition to using the Hollywood principle with the Template Method be sure to keep in mind that it is a general principle. If you ever call a higher level object with a lower level object, you’re bound to get in trouble, and as they say,

You’ll never work in this town again!

So just remember the Hollywood principle and let the higher level object make the call.

Because the classes for handling audio were set up around the Sound class, I thought this would be a major chore, but all I had to do was to make changes in one class. After the changes were made, it worked fine. The best part is that the structure of the Template Method did not interfere with any of the other elements in the application. So while the application may be fairly complex for the simple task of playing video and sound, when things change, as they always do, making the changes in the application were simple.

The application can be found at: http://www.sandlight.com/player9/. Keep in mind that no FLV files are used but that a genuine MOV file being played in Flash using progressive download and the sound is from a M4a file, the same file format as the ones used for iTunes–all sitting fat and happy and working. You’ll need to go to Adobe Labs and download the Flash 9 player (Beta) to see this at work.