ActionScript 3.0 Design Patterns

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.

Two-day Design Pattern Workshop on CCNY campus of CUNY

The last talk I gave was also in NYC, and I went over the Strategy pattern in ActionScript 3.0. This time, I’ll be looking at using the State Design pattern in creating an AS3 state machine. Also, since the class diagrams of the Strategy and State look identical, I’ll be differentiating between the two. There’s a world of difference once you get to know them. On the PHP side, I’ll be looking at setting up a Strategy design pattern for use issuing SQL commands as unique algorithms and explore the little known fact that in PHP interfaces can have constants and how to program to an interface in a language that is weakly typed.

Schedule

The workshop will take place in the Amsterdam Room of the students cafeteria in the North Academic Center (NAC) Building of the beautiful campus of the City College of New York at 160th Convent Avenue, New York, NY 10031. The school campus is located a short walk from the A, B, C, and D trains at the 145th street station, and the #1 train at the 137th street station.

Day 1 ~ 13thth January, 2011
Breakfast: 8:30AM – 9:00AM

Object Oriented Programming in PHP: 9:00AM – 12:00PM
Reviewing PHP
OOP in PHP
Classes in PHP
Abstract classes and Interfaces
Programming to an interface
Lunch: 12:00PM – 12:35PM

SQL commands in PHP using mysquli structures: 12:35PM- 2:45PM
Re-thinking programs with Design Patterns
The Strategy Design Pattern: Encapsulating Algorithms
Starting with Data Entry and Data Read Algorithms
Adding more Algorithms by implementing more Strategy classes
The ease of change
Coffee Break: 2:45PM – 3:00PM

Using type hinting in a weakly typed language: 3:00PM – 4:00PM

Day 2 ~ 14th January, 2011
Breakfast: 8:30AM – 9:00AM

Client-side programming in ActionScript 3.0 with Video objects: 9:00AM – 12:00PM

Using NetConnection and NetStream objects
Streaming video and progressive download
Object Oriented Programming with ActionScript 3.0
Lunch: 12:00PM – 12:35PM

OOP in ActionScript 3.0: 12:35PM – 2:45PM
Basic OOP concepts
The concept of a State Machine (State Engine): Statecharts
Creating a video player as a State Machine
Coffee Break: 2:45PM – 3:00PM

State Design Pattern: 3:00PM – 4:00PM
Context class
State Interface
Concrete States
Adding states and changing states

The Coders Algonquin Round Table

In addition to the regular schedule, I’m hoping to bend an elbow at the Algonquin Hotel lounge. We can have an informal OOP/DP roundtable and pretend we’re the coder version the original Algonquin Round Table–Dorothy Parker, Robert Benchley, Edna Ferber, George S. Kaufman, Robert Sherwood and Tallulah Bankhead. The Algonquin is located at 59-63 44th Street between Fifth and Sixth Avenues. Right around six o’clock on the evening of January 13. At the FCNY meeting last summer, I didn’t get a chance for an informal chat with many of you, and I don’t want to make that mistake again.

Getting Started in Design Patterns Can be Daunting

What are Design Patterns?

So as not to create false expectations, Design Patterns will not make your programs run faster or better. They were developed to aid in creating object oriented programs that can be reused and easily changed and updated. One of the side benefits is that they aid in understanding Object Oriented Programming (OOP); so, if you leap into design patterns, you’re leaping into OOP.

They’re not easy, but don’t let that scare you. Some are easier than others, and by starting with the easy ones, the more challenging ones will come in time.

They payoffs are huge. If you’re reading this line, it means you’re not afraid of expanding your mind beyond what you thought you could do in programming. Once you’ve figured out ‘Hello World’ level programming and discovered the beauty of a good algorithm, it’s time to look at the bigger picture. So let’s get started!
Read more…