Hollywood Principle: Don’t Call Us; We’ll Call You—ActionScript 3.0 Template Design Pattern goes Hollywood!

The problem in understanding the Hollywood Principle is that it is too often glossed over as a type of inversion of control. In most respects, the Hollywood principle is really about the direction of calls. Where it gets a little confusing is when you assume the natural order of programming is from bottom to the top, with the bottom making calls to the higher levels. At one time, much programming was “bottom-up” in this sense, but that’s been quite a while. Therefore, when talking about inversion, you may be wondering, inversion from what? In fact, the late John Vlissides (one of the Gang of Four) starts off a discussion of the Hollywood Principle, noting,

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.

The Hollywood Principle: Don’t Call Us; We’ll Call You—ActionScript 3.0 Template Design Pattern goes Hollywood! by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Related posts:

1. Design Pattern Principles for ActionScript 3.0: The Liskov Substitution Principle
2. Design Pattern Principles for ActionScript 3.0: The Open/Closed Principle
3. Design Pattern Principles for ActionScript 3.0: Single Responsibility Principle