However, since we agreed to let you decide, our next post will be to get those who are beginning, intermediate and advanced programmers through the worm hole and into the land of OOP and Design Patterns.

In the meantime ponder this: C’est magnifique, mais ce n’est pas la guerre. C’est de la folie. That’s how the new series begins.

I’m working on a new post about ActionScript 3.0 Design Patterns at work. To help get an accurate measure of what folks are doing in the ActionScript work world, I put together a simple survey. The survey is made with radio buttons and check boxes; so it only takes a minute to fill out. Click below to take the World’s Easiest Survey:

ActionScript Design Patterns at Work Survey

We thank you in advance, and when we get the post up, you’ll see the results from the survey.

Okay, here’s a chance for Fame and Fortune. (We’ll supply the former; you supply the latter.) On Monday, April 27 you’ll find a new ActionScript 3.0 Easy and Practical Decorator Lunch Bucket Pattern on this blog. The contest will begin on Monday, April 27 and end Friday May, 22–2009. (That’s not a lot of time! But it should not take a lot of time to make the changes.) You can download the Decorator files here .

The contest is to see if you can change the Decorator design pattern in the new post, ActionScript 3.0 Easy and Practical Decorator Design Pattern.
Using the provided Component class (no changes allowed) and the provided Decorator class (no changes allowed) add new or changed Concrete Components and/or Concrete Decorators to make the most interesting program using the Decorator Design Pattern.

We have four age categories, and each category will have 1st, 2nd, and 3rd prizes. The Grand Prize will be given to the very best entry, regardless of age. Here are the categories:

• Under 18
• 18-25
• 26-40
• Over 40

All winners will be displayed on this blog along with their entries and photos. Read on to learn the rules.

The Rules

1. You cannot change the code in the Component Class
2. You cannot change the code in the Decorator Class
3. You can only request concrete decorators or components from the Client class
4. You cannot change the interfaces or signatures in the concrete decorator or component classes
5. You cannot add bitmapped graphics or load external bitmapped or SWF files.
6. You can add UI components to the Client class only and only for making requests for concrete decorators or components.
7. All entries must be compacted in .zip format
8. Either Adobe Flex Builder or Flash may be used—if it’s all code you could use Note Pad or TextEdit I suppose.
9. All ActionScript must be version 3.0

If any of the rules are broken, the entry will be disqualified.

All inquiries about the Contest must be made to the Comments Section of this blog entry. The reason is that if one person has a query, there’s usually a dozen more with the same question, and it saves time to respond to a single query than many. (No email inquires will be answered).

All entries must have the following:

Name
Age
Subject Line in email: Golden Lunch Bucket Contest
Attached .zip file with your entry

Email entries to: Bill Sanders: wdsanders@comcast.net

No entries will be accepted after May 22, 2009

myMC_high.myMC_middle.myMC_lower.myMC_lowest.DoSomething()…

break the principle of Least Knowledge because it implies that each has some knowledge of the inner workings of the others. Likewise, anyone who has spent much time with JavaScript and the Document Object Model (DOM) knows that many of the objects have some hefty drill-downs in references. According to the Least Knowledge Principle, these are all ways to ask for trouble. Let’s see why.

One Dot Over the Line

First of all, few principles have as many names as the Least Knowledge Principle. Here they are—as an aid to remember what the point is and resource to find out more.

1. Law of Demeter: This term emanated from Northeastern University’s Demeter project. The name Demeter is from the goddess of agriculture which (to me) is more confusing than helpful. The Law of Demeter states:
   

   A method “M” of an object “O” should invoke only the methods of the following kinds of objects:

   • itself
   • its parameters
   • any objects it creates/instantiates
   • its direct component objects

   The Law of Demeter is the most specific as to what you should invoke as far as methods are concerned. Remember these four objects—the object itself, its parameters, instantiated objects and direct component objects.

2. One Dot Rule: Of all of the names for the Least Knowledge principle, the One Dot Rule is the most helpful in terms of a simple formula to remember. However, the advice to “use only one dot” is often the subject of heated (is there any other type?) debate among programmers. Generally, they miss the point, which is that any change in between the dots can be catastrophic when making changes. For example a statement like,
   object1.object2.object3.methodA();
   can have dire consequences if one changes either object2 or object 3.
3. French Mistress Rule (entre nous): This one doesn’t count since I coined it for our more romantic readers. It’s also known as the Secret Lover Principle, with the main idea being that if you carry on une affaire du coeur you had better keep it between you and your amoureux. As you can imagine, this helps remind you that you don’t want to provide anyone with more information than they can handle or need. What usually happens in these situations is that you just communicate with your closest friends—just as you should in programming.

Some will conclude that this principle sounds a lot like delegation and why bother with a redundant principle? Well, in a nutshell, it is a lot like delegation—some might even say it’s just another name for delegation. I cannot argue with that point, because delegation is definitely implied in this Least Knowledge Principle. However, the principle is very instructive in that it points out a very specific way to think about coding and building programs. So while it’s a lot like delegation, it focuses on a specific aspect of delegation and organizing a program.

Least Knowledge in Design Patterns

Given all of those different angles on the Least Knowledge Principle, you may wonder what all of this has to do with design patterns. Remembering that the purpose of design patterns is to generate reusable code and programs that are easy to change, the principle keeps us from tangling up our references with too much information that may change in different parts.

Probably the best example of the Least Knowledge Principle at work is the Façade Design Pattern. (In fact, in the Façade post, we noted that the Least Knowledge Principle was at work.) In the Façade, instead of making requests through the myriad of classes in another system, all requests are made through the Façade. The requester (Client in this case) just communicates with the Façade and doesn’t know or need to know the details of the other classes. Thus, it can communicate just with its close friends and not become entangled in all of the subsystem classes.

Other Least Knowledge examples can be found in design patterns that use wrappers. In the Proxy pattern, the Client does not communicate with the concrete class, but instead makes requests through a proxy class. Likewise, the Decorator and the Adapter patterns (Chapters 4 and 5 in our book) use wrappers to keep the structure loose and adaptable. In the Decorator, the requests are made through the decorators (wrappers) to the concrete classes that reference the concrete classes as parameters in the instantiation of a decorator. Likewise in the Adapter, requests are through a target interface instance of an adapter object to any adaptee component. The client has no idea of the details and does not need them.

Into the Lunch Bucket
The Least Knowledge principle is easy to remember by at least one of the names it’s called. Using the “use only one dot” rule, you’ll find yourself better off in terms of what might break. Of course we have to live with exceptions, such as the Shape.graphics.method() statements built into ActionScript 3.0 (for the time being at least), but you really need to rethink setting up movie clips within movie clips within movie clips, ad nauseam.

Those who prefer to use the term Law of Demeter seem to have the best horror stories. In one such story I came across, the Law of Demeter was broken in some software that was being used for the Mars pathfinder, and you can imagine the problems that would have caused—your programmer isn’t going to make a house call on that one!

We have found, however, that breaking the LoD (Law of Demeter) is very expensive! On Mars Pathfinder, the integration costs of the law breaking parts of the system were at least an order of magnitude higher, and we had to pay that cost on every integration cycle — not just once! We should have paid the cost once by implementing a more sophisticated protocol that did obey the LoD. (Email from David.E.Smyth at NASA’s JPL.)

Also, Miško Hevery’s article on breaking the Law of Demeter is quite good. He uses the analogy of finding a needle in a haystack for the debugging process where the law has been violated. Now put that together with trying to fix a buggy program on the Mars pathfinder!

It’s easier for me to think of the principle in terms of only speaking to your immediate friends or keeping it entre nous. It works best for thinking in terms communicating in shorter links—sort of like a line of people holding hands and just talking to the person on the left or right. It’s not exactly that restrictive, but it helps me to keep the concept in my head. In an upcoming post on the Decorator design pattern on this blog, I hope to show how the Least Knowledge principle is applied in a wrapper application.

In the meantime, take this principle to work in your lunch bucket. If you call a method, remember to keep it close to the vest, and your objects need to know as little as possible about the internal structures of the methods they call outside of their own structure. You should never hear your objects mutter, that’s way more than I needed to know.

I had a meeting with a computer scientist who was teaching a game class. In our short chat, he must have used the term real world a dozen times. Well, I’m all for the real world (in contrast to the unreal world of unicorns, fairy dust, and honest politicians). However, the real world for one is not the same as it is for another. Recently, I got a comment about a blog entry thanking us for a solution to a practical problem that one of our readers encountered in programming. The same post was criticized by another reader as not being real world. Therein lies the dilemma.

Abstract vs. Concrete

Chandima and I use a range of examples in our book. We start with an abstract minimalist example so that the reader can see the participants in a design pattern and then move on to something more concrete to illustrate a practical application. On this blog, most of the examples start with the more abstract elements and move into a fairly general (somewhat abstract) example that is more practical. The more abstract an example, the more general its applicability—not unlike an abstract class. However, the more concrete an example, the better the reader can use it to model a like problem in an eminently practical way. Each has its benefits. The abstract examples have generalizability and the concrete examples have needed detail.

Were I to do all of my examples using real world examples that I deal with, most would involve streaming video and Flash Media Server. My customers usually approach me for just that kind of problem. Obviously,using streaming video and FMS is real world, but its not very generalizable. Likewise, some readers complain that the abstract examples don’t help because they’re not practical.

We’d like your thoughts on this issue. Obviously, the most useful examples would be those that you deal with directly in your work, but like my practical work, it’s pretty narrow. Keeping these concerns in mind, tell us what’s most helpful to you.

This is one of the few design patterns that I worked up directly from the class diagram and from concepts in GoF. Normally, I like to look at some examples, done in Java or C#, but not this time. As you will see in Figure 1, the pattern appears to be fairly daunting, but I found it to be eminently practical, and it seemed to be a direct response to questions that I had about the Factory Method design pattern (See Chapter 2 for an in-depth explanation of the Factory Method.) You can download the entire example here before continuing if you wish.

 Let me start with the gist of the example from GoF and provide something more concrete that’s likely to be a typical kind of issue Flash and Flex developers deal with. Imagine a project where your designers have created general templates for a business site and another for a game site. Their templates include a SWF background and a set of buttons for a UI. The buttons are wholly programmed and require nothing in the Library, and so using them for either Flash or Flex is fairly simple.

 You want to keep your design loose, and so you decide that a factory will be helpful. However, clearly you will need a factory to create instances of both buttons and the background template. Further, you want your products to derive from an abstract class to give you as much flexibility as possible. In the example here, you will need an abstract product for buttons and another for backgrounds. You also want your factory abstract enough to make requests for sets of objects from the different products. For example, you want your factory to deliver both a set of buttons and a background that are matching pairs. You don’t want a set of buttons for a game site with a background for a business site, but rather you want the buttons to match your background—business buttons with a business background and game buttons with a game background. This is a job for the Abstract Factory.

 Figure 1 shows the class diagram. In looking at the “create” lines (dashed lines), think of them as working with matched sets. The Client requests a business set; and it gets both a business product for buttons and another product for background. So while the diagram may look busy, it really is doing something that makes sense on a basic level. That is, the design is geared to sets; of products with factories that create the requested sets rather than individual objects.

Figure 1: Abstract Factory Class Diagram
Note that Figure 1 shows that both concrete factories create instances from each of the child classes of the two abstract product classes. You can very quickly see the practicality of this when you substitute some concrete elements for the more general conceptual names.

Buttons and Backgrounds

A simple project to use as an example is a program that loads a buttons-background pair. The buttons are made using the SimpleButton class, and the backgrounds are SWF files created using Flash. Figure 2 shows the class diagram for the sample project:

Figure 2: Example of Abstract Factory
The two button classes (RoundBtn and RecBtn) dip into a buttons folder where they pick up the buttons. These other classes not in the diagram can be thought of as helper or utility classes. Likewise, the two SWF files might be considered utility objects in the mix. Figure 3 shows the actual files and folders arranged in the class diagram.

Figure 3: File Diagram of Abstract Factory

No lines go to either the buttons folder or the two .swf files. They’re really not part of the pattern but rather resources (helpers if you wish) for the different participants. If we did add lines, they’d be dashed ones to indicate that the product subclasses create instances of the helpers.

The Client

The Client is a busy object in this design. It holds references not only to the abstract factory (AbFactory) it also holds references to all abstract product classes. The important point here is that by holding references to an interface (the abstract classes), the Client doesn’t get bogged down with specific dependencies. If any of the concrete classes change, the client’s references can handle it. Let’s take a look at the code for this key participant in the 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

{
	import flash.display.Sprite;
 
	public class Client extends Sprite
	{
		private var busFactory:AbFactory;
		private var gameFactory:AbFactory;
 
		private var btn1:ProductA;
		private var btn2:ProductA;
		private var btn3:ProductA;
 
		private var gameWall:ProductB;
		private var busWall:ProductB;
 
                private var btnX:int;
 
		public function Client()
		{
 
			busFactory=new BusinessFactory();
			btnX=20.9;
			busWall=busFactory.createProductB();
			addChild(busWall);
 
			btn1=busFactory.createProductA("Accounts");
			addChild(btn1);
			btn1.x=btnX, btn1.y=224;
 
			btn2=busFactory.createProductA("Factory");
			addChild(btn2);
			btn2.x=btnX, btn2.y=272;
 
			btn3=busFactory.createProductA("Production");
			addChild(btn3);
			btn3.x=btnX, btn3.y=320;
 
			//Move block comment symbols to change
                       // from business to game
/*
			gameFactory=new GameFactory();
			btnX=18;
			gameWall=gameFactory.createProductB();
			addChild(gameWall);
 
			btn1=gameFactory.createProductA("Fire");
			addChild(btn1);
			btn1.x=btnX, btn1.y=224;
 
			btn2=gameFactory.createProductA("Move");
			addChild(btn2);
			btn2.x=btnX, btn2.y=272;
 
			btn3=gameFactory.createProductA("Hide");
			addChild(btn3);
			btn3.x=btnX, btn3.y=320;
 
			// Don’t forget to move close comment block symbol
*/
		}
	}
}

The first item to note is how the Client class holds references to both the abstract factory and abstract product:

private var busFactory:AbFactory;
private var gameFactory: AbFactory;
…
private var btn1: ProductA;
private var btn2: ProductA;
private var btn3: ProductA;
…
private var gameWall: ProductB;
private var busWall: ProductB;


In this particular example, the choices for a business or game site are separated by commenting out one of the sites. In this case, the business site appears. Of course you can add a UI that would call up one or the other, but this approach seemed a bit clearer. To see one or the other, just change the position of the comment characters (/* and */). So using the default comment characters, when you test the program, Figure 4 shows what you’ll see initially:

Figure 4: Business Site and Buttons

By moving the comment symbols to block out the business options and opening the game options, you’ll see an entirely different background and button set. Figure 5 shows the dramatic difference.

Figure 5: Game Site and Buttons

By comparing Figures 4 and 5, you can see an entirely different set of buttons and background. The square in the middle rotates to further distinguish the game products from the business ones. (I know, gratuitous use of animation. Sorry.)

The Abstract and Concrete Factories

The abstract factory allows far more flexibility than a concrete factory. Because the backgrounds and buttons are clearly different kinds of products, it makes perfect sense to have different kinds of factories to generate the products. The utility of the abstract factory can be seen in the different kinds of concrete factories. As you will see, the concrete factories are only slightly different. Each must create an instance of all products classes (ProductA and ProductB in the example), but because the concrete classes are different they must create different concrete class instances. In this example, The GameFactory and BusinessFactory classes create different buttons and backgrounds and yet each is a child of the abstract factory class. The following listing shows the factory 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
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

//Abstract Factory
package
{
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class AbFactory extends Sprite
	{
		public function createProductA(txt:String):ProductA
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		public function createProductB():ProductB
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
	}
}
 
//Game Factory
package
{
	public class GameFactory extends AbFactory
	{
		private var gameBtn:ProductA;
		private var gameWall:ProductB;
 
		override public function createProductA(txt:String):ProductA
		{
			gameBtn = new RoundBtn(txt);
			return gameBtn;
		}
 
		override public function createProductB():ProductB
		{
			gameWall=new GameStyle();
			return gameWall;
		}
	}
}
 
//Business Factory
package
{
	public class BusinessFactory extends AbFactory
	{
		private var businessBtn:ProductA;
		private var businessWall:ProductB;
 
		override public function createProductA(txt:String):ProductA
		{
			businessBtn = new RecBtn(txt);
			return businessBtn;
		}
 
		override public function createProductB():ProductB
		{
			businessWall=new BusinessStyle();
			return businessWall;
		}
	}
}

As you can see, each child factory returns its own unique set of buttons and background as shown in Figures 4 and 5 above.

The Abstract Products and their Children

The design pattern shows two abstract products, but you can think of them as at least two products. You can have as many products as you want, but for each abstract product, you need a concrete factory. To help keep everything clear, the abstract product classes were named ProductA and ProductB. The “A” products are buttons and the “B” products are backgrounds. As you can see in the following listings, each is different. Both include abstract methods, but ProductB has a heavily parameterized method, setWallName to add flexibility to the placement of a page header. To help keep everything clear, first you will see the abstract product and then the two concrete children classes for each.

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
142
143
144
145
146
147
148
149
150
151
152

//Product A: The buttons
package
{
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class ProductA extends Sprite
	{
		protected function setUpA(txt:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
	}
}
 
//Round Button concrete product
package
{
	import buttons.BtnStateEllipse;
 
	public class RoundBtn extends ProductA
	{
		private var btnStateEllipse:BtnStateEllipse;
 
		public function RoundBtn(txt:String)
		{
			setUpA(txt);
		}
 
		override protected function setUpA(txt:String):void
		{
			btnStateEllipse = new BtnStateEllipse(txt);
			addChild(btnStateEllipse);
		}
	}
}
 
//Rectangle button concrete product
package
{
	import buttons.BtnState;
 
	public class RecBtn extends ProductA
	{
		private var btnState:BtnState;
 
		public function RecBtn(txt:String)
		{
			setUpA(txt);
		}
 
		override protected function setUpA(txt:String):void
		{
			btnState = new BtnState(txt);
			addChild(btnState);
		}
	}
}
 
//Product B: The Backgrounds
package
{
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
	import flash.text.TextField;
	import flash.text.TextFormat;
	import flash.text.TextFieldAutoSize;
 
	public class ProductB extends Sprite
	{
 
		protected function setWallName(wall:String,sz:int,hor:int,vert:int,txtField:TextField,format:TextFormat):void
		{
			txtField.text=wall;
			txtField.x=hor, txtField.y=vert;
			txtField.autoSize=TextFieldAutoSize.CENTER;
			format.size=sz;
			format.font="Arial Black";
			txtField.setTextFormat(format);
			addChild(txtField);
		}
 
		protected function setUpB():void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
	}
}
 
//Game Background
package
{
	import flash.display.Sprite;
	import flash.display.Loader;
	import flash.net.URLRequest;
	import flash.text.TextField;
	import flash.text.TextFormat;
 
	public class GameStyle extends ProductB
	{
		private var loader:Loader;
		private var url:URLRequest;
		private var txtField:TextField=new TextField();
		private var format:TextFormat=new TextFormat();
 
		public function GameStyle()
		{
			setUpB();
			setWallName("Game Time!",24,200,30,txtField,format);
		}
 
		override protected function setUpB():void
		{
			loader=new Loader();
			url=new URLRequest("GameStyle.swf");
			loader.load(url);
			addChild(loader);
		}
	}
}
 
//Business background
package
{
	import flash.display.Sprite;
	import flash.display.Loader;
	import flash.net.URLRequest;
	import flash.text.TextField;
	import flash.text.TextFormat;
 
	public class BusinessStyle extends ProductB
	{
		private var loader:Loader;
		private var url:URLRequest;
		private var txtField:TextField=new TextField();
		private var format:TextFormat=new TextFormat();
 
		public function BusinessStyle()
		{
			setUpB();
			setWallName("Serious Business",24,200,30,txtField,format);
		}
 
		override protected function setUpB():void
		{
			loader=new Loader();
			url=new URLRequest("BusinessStyle.swf");
			loader.load(url);
			addChild(loader);
		}
	}
}

By requesting the game products, the program returns both the rectangle shape buttons and the game background, and likewise with a request to the business products returns the business set. The separate concrete factories keep everything loose and the pattern has very few dependencies.

The Helpers

The RoundBtn class imports an ellipse button from the buttons package:

import buttons.BtnStateEllipse;

and the RecBtn class imports a rectangle button from the buttons package:

import buttons.BtnState;

So in creating the button scripts, the package indicates the buttons folder. The following scripts are found in the buttons folder. These helper classes are reusable just like the participants in a design pattern. However, because literals are used in these for the colors used with the button states, their flexibility is limited to the particular style and color scheme in the buttons.

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

//Button style for games
package buttons
{
    //Ellipse shape
	import flash.display.Sprite;
	import flash.display.Shape;
	import flash.text.TextFormat;
	import flash.text.TextField;
	import flash.text.TextFieldAutoSize;
 
	class BtnBaseOval extends Sprite
	{
		private var btnLabel:TextField;
		private var format:TextFormat;
		private var btnWidth:Number;
		private var bkground:Shape;
 
		public function BtnBaseOval (color:uint,color2:uint,btnLabelText:String)
		{
			btnLabel=new TextField();
			btnLabel.text=btnLabelText;
			btnLabel.x=5;
			btnLabel.textColor=0x24241c
			btnLabel.autoSize=TextFieldAutoSize.CENTER;
 
			format=new TextFormat("Arial Black");
			format.size=12;
			btnLabel.setTextFormat (format);
			btnWidth=90;
 
			bkground=new Shape;
			bkground.graphics.beginFill (color);
			bkground.graphics.lineStyle (.25,color2);
			bkground.graphics.drawEllipse (0,0,btnWidth,18);
 
			addChild (bkground);
			addChild (btnLabel);
		}
	}
}
 
//Button states and colors game buttons
package buttons
{
	import flash.display.SimpleButton;
 
	public class BtnStateEllipse extends SimpleButton
	{
		public function BtnStateEllipse (txt:String)
		{
			upState = new BtnBaseOval(0x698c3a, 0x218894,txt);
			downState = new BtnBaseOval(0xc7c68d,0x4d0005, txt);
			overState= new BtnBaseOval(0x48f23,0x218894,txt);
			hitTestState=upState;
		}
	}
}
 
//Button style for Business
package buttons
{
	//Set up rectangular shape
	import flash.display.Sprite;
	import flash.display.Shape;
	import flash.text.TextFormat;
	import flash.text.TextField;
	import flash.text.TextFieldAutoSize;
 
	class BtnBaseRec extends Sprite
	{
		private var btnLabel:TextField;
		private var format:TextFormat;
		private var btnWidth:Number;
		private var bkground:Shape;
 
		public function BtnBaseRec (color:uint,color2:uint,btnLabelText:String)
		{
			btnLabel=new TextField() ;
			btnLabel.text=btnLabelText;
			btnLabel.x=5;
			btnLabel.textColor=0x24241c;
			btnLabel.autoSize=TextFieldAutoSize.LEFT;
 
			format=new TextFormat("Verdana");
			format.size=12;
			btnLabel.setTextFormat (format);
			btnWidth=90;
 
			bkground=new Shape;
			bkground.graphics.beginFill (color);
			bkground.graphics.lineStyle (.25,color2);
			bkground.graphics.drawRect (0,0,btnWidth,18);
 
			addChild (bkground);
			addChild (btnLabel);
		}
	}
}
 
//Button states and colors business buttons
package buttons
{
	import flash.display.SimpleButton;
 
	public class BtnState extends SimpleButton
	{
		public function BtnState (txt:String)
		{
			upState = new BtnBaseRec(0xa9b890, 0x24241c,txt);
			downState = new BtnBaseRec(0xffff7f8,0xcd1722, txt);
			overState= new BtnBaseRec (0xcd1722,0xa9b890,txt);
			hitTestState=upState;
		}
	}
}

In looking back over this example, keep in mind that these last set of classes, the helper classes, are not part of the pattern itself. Rather, they are used to make it easy to create buttons without resorting to either the button symbols made in Flash or Flex. However, if you’d prefer the factories to use the built-in button components rather than those in the helper classes, you will find it easy to do so. Just change the targets of creation in the concrete product classes where the buttons are assigned.

When to Use the Abstract Factory

The key element in the Abstract Factory Design Pattern is the idea of families of related dependent objects. After working with the pattern for a very short time, it offered up many solutions in my mind. None of us work with single programs—single projects at one time, certainly—but these projects are hardly single programs. They do indeed have certain parts that go together in one context but not another. So instead of having to work up an entire new program to work with families of these objects, this pattern allows you the convenience of working with one group or another depending on the project’s needs.

Note: Chandima wrote the chapter in our book on the Factory Method, and he gave me invaluable help on the main program in this post as well.

Recap

Up to this point we’ve examined a simple program that loads external text and graphics, a common ActionScript chore. In the most general terms, this is where we’ve been:

• Part I: Identifying the problem in a current solution. Why ActionScript on the Timeline can cause problems.
• Part II: Providing a simple OOP solution: Use of Inheritance
• Part III: Loosening Up a programs structure: Adding a design pattern element —a simple factory

To conclude the process, we now come to the last part—introducing an actual design pattern to the work place.

• Part IV: Establishing a Design Pattern Foundation.

Given the preceding steps, the context is now in place to add a full design pattern.

From Part to Whole

Part III introduced the Simple Factory method inserted into an existing OOP program. Now it’s time to step back and look at a design pattern en toto and instead of incrementally adding to the existing program, we will refactor the whole kit-n-kaboodle from the perspective of a design pattern.

To get started, if you’re not familiar with the Factory Method pattern, take a look at Chapter 2. In fact Chandima’s Sprite Factory example beginning on page 84 is one of the clearest and most appropriate examples that you can find of the Factory Method pattern in ActionScript 3.0. So before continuing, you might want to do a quick review of the Factory Method and take a look at Figure 1, the class diagram for the pattern. (We’ll wait for you…).

Figure 1: Factory Method Design Pattern

As you can see, the Factory Method (simple factory) is part of the Creator interface and the ConcreteCreator. The interface is an abstract class; so at least one of the methods needs to be abstract—impossible to directly instantiate but easily overridden in a child class.

The Product class is an abstract version of what we called the Staff class in the previous version of the application. Again, using an abstract class requires abstract methods to be overridden in the child classes. The ConcreteProduct classes were previously the Designer, Developer and HCI classes. We can keep the old designations for clarity, but their parent class is now the Product interface (abstract class). That means that the child classes can now make adjustments to the methods using the override statement. However, those methods not overridden do not need to be revised at all. Figure 2 shows the design pattern (without the pseudo-code blocks.) and with the actual child classes for the Product abstract class.

Figure 2: Factory Method Pattern applied to current project

As a reminder, the dashed lines with the arrows means that origin of the dashed line creates an instance of the class to which the arrowhead points.

One Day They Came to Work and Found All These Design Patterns

In the process of creating this series of posts and working on a presentation for the Atlanta group with similar aims, I’ve been able to review the process of introducing design patterns at work. My conclusion is that we need to step both gently and firmly, and by all means do so in a practical way. (When the choice is between being on time and being right, take on time.) However, OOP and design patterns need to be at the back of your mind so that you can begin viewing projects in terms of OOP and design patterns. In turn, this will make your company’s products better, more flexible and less likely to choke up at the wrong time. (They never choke up at the right time—whenever that is.)

So, in looking at this refactored program, keep in mind that we started with a simple program embedded in the Timeline using keyframes to choose graphic and text images. Also, keep in mind the problem, and how the design pattern became a solution for that problem.

The Client Looks the Same

We’ll start with the Client, and not surprisingly, it is little changed from last time. However, the request is typed to an abstract class this time (factory:Creator).

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

package
{
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	//Client Class
 
	public class Client extends Sprite
	{
		private var logo:Sprite = new Logo();
		private var splash:Sprite = new Splash();
		private var desBtn:Button = new Button();
		private var devBtn:Button = new Button();
		private var hciBtn:Button = new Button();
		private var staffNow:String;
		private var staffDisplay:Sprite;
		private var staff:String;
		private var factory:Creator=new ConcreteCreator();
 
		public function Client()
		{
			desBtn.label = "Designer";
			desBtn.addEventListener(MouseEvent.CLICK,selectStaff);
			addChild(desBtn);
			desBtn.x = 424,desBtn.y = 66;
 
			devBtn.label = "Developer";
			devBtn.addEventListener(MouseEvent.CLICK,selectStaff);
			addChild(devBtn);
			devBtn.x = 424,devBtn.y = 116;
 
			hciBtn.label = "HCI";
			hciBtn.addEventListener(MouseEvent.CLICK,selectStaff);
			addChild(hciBtn);
			hciBtn.x = 424,hciBtn.y = 166;
 
			logo.x = 16,logo.y = 16;
			logo.width = 150,logo.height = 121.5;
			addChild(logo);
 
			splash.x = 32,splash.y = 168;
			addChild(splash);
		}
 
		private function selectStaff(e:MouseEvent)
		{
			staff = e.target.label.toLowerCase();
			splash.visible=false;
 
			if (staffDisplay)
			{
				removeChild( staffDisplay );
			}
 
			staffDisplay = factory.makeStaff(staff);
			addChild( staffDisplay );
		}
	}
}

This next class, the Creator, is an abstract one. The functionality of this class is not appreciated in this particular application because we derive only a single child from it. However, if we wanted to change the program to create other elements that we may wish, such as a button factory we could do so relatively easily, and because of the loose linkage, adding another child will not disrupt the overall program.

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
{
	//Asbstract class
	//Creator
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class Creator
	{
		private var staffNow:Sprite;
 
		public function makeStaff(staff:String):Sprite
		{
			staffNow = createStaff(staff);
			return staffNow;
		}
 
		// ABSTRACT Method (must be overridden in a subclass)
		protected function createStaff(staff:String):Sprite
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
			return null;
		}
	}
}

The Creator provides the abstract method for the factory in the Factory Method design pattern. The ConcreteCreator is where the actual factory work is accomplished.

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

package
{
	//Factory
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class ConcreteCreator extends Creator
	{
		override protected function createStaff(staff:String):Sprite
		{
			switch (staff)
			{
				case "designer" :
					return ( new Designer() );
					break;
				case "developer" :
					return ( new Developer() );
					break;
				case "hci" :
					return ( new HCI() );
					break;
				default :
					throw new Error("Invalid type of staff specified");
					return null;
			}
		}
	}
}

As you can see, that’s almost identical to the Factory class in Part III of this series of posts. The createStaff() method is overridden. Because it is a child of the Creator class, it has the makeStaff() method, and it uses the creatStaff() method in any way that it has been overridden in the concrete creator itself.

The Product and Its Children

A second abstract class, Product, as noted above, is very similar to the Staff class introduced in Part II of this series. The difference is that the Staff class was concrete and the Product class is abstract. Two of its methods are abstract, and both need to be overridden and detailed in the child classes. So instead of inheritance to a concrete class with no flexibility, the child classes of the Product can customize the overridden functions. The following shows how the Product class is set up:

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

package
{
	import flash.errors.IllegalOperationError;
	import flash.net.URLLoader;
	import flash.display.Sprite;
	import flash.text.TextField;
	import flash.text.TextFieldType;
	import flash.events.Event;
	import flash.text.TextFormat;
 
	//Abstract class
	public class Product extends Sprite
	{
		private var loadCheck:URLLoader;
		private var txtFld:TextField = new TextField();
		private var textFormat:TextFormat = new TextFormat();
		private const WIDE:int=200;
		private const TEXTCOLOR:uint=0x007700;
 
		protected function loadInfo(txtInfo:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		protected function nowLoaded(e:Event):void
		{
			loadCheck = URLLoader(e.target);
			textFormat.font = "Arial Black";
			textFormat.size = 16;
			txtFld.type = TextFieldType.DYNAMIC;
			txtFld.width = WIDE;
			txtFld.wordWrap = true;
			txtFld.textColor =TEXTCOLOR;
			txtFld.defaultTextFormat = textFormat;
			txtFld.text = loadCheck.data;
			addChild(txtFld);
			txtFld.x = 180,txtFld.y = 331;
		}
 
		protected function loadImg(img:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
 
		}
	}
}

The Product has two abstract and one concrete methods. The thinking is that the onLoaded() operation is not going to change, but is needed to have everything laid out for the incoming Sprite object containing the image and text. However, we might come up with positioning ideas for the image that we can change. As for the abstract method for adding the text, it’s probably not going to change, but if it does, we can make the changes in the child classes. If we want to re-position the text, we can still use the concrete method in the Product class itself to change all text.

The result of having abstract methods is that they need to be filled out (populated by code) in the child classes. As a consequence, the concrete Product classes (Designer, Developer, and HCI) are all larger than the tiny ones in previous posts in this series. They have to override the abstract methods and add the code they want. In this example, they’re virtually identical to one another, but if we wanted to change one, we could do so without interfering with the other concrete child Product classes. The following three classes show how the concrete products are created:

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
142
143

//Designer
package
{
	import flash.net.URLRequest;
	import flash.display.Loader;
	import flash.net.URLRequest;
	import flash.net.URLLoader;
	import flash.display.Sprite;
	import flash.events.Event;
 
	public class Designer extends Product
	{
		private var staffText:String;
		private var staffImg:String;
		private var url:URLRequest
		private var loader:Loader
		private var fileNow:URLRequest;
		private var txtLoader:URLLoader;
		private var loadCheck:URLLoader;
 
		public function Designer()
		{
			staffText = "text/designer.txt";
			staffImg = "images/designer.png";
 
			loadInfo(staffText);
			loadImg(staffImg);
		}
 
		override protected function loadInfo(txtInfo:String):void
		{
			txtLoader = new URLLoader();
			txtLoader.addEventListener(Event.COMPLETE,nowLoaded);
			fileNow = new URLRequest(txtInfo);
			txtLoader.load(fileNow);
		}
 
		override protected function loadImg(staffImg:String):void
		{
			url = new URLRequest(staffImg);
			loader=new Loader();
			loader.load(url);
			addChild(loader);
			loader.x = 180,loader.y = 131;
		}
	}
}
 
//Developer
package
{
	import flash.net.URLRequest;
	import flash.display.Loader;
	import flash.net.URLRequest;
	import flash.net.URLLoader;
	import flash.display.Sprite;
	import flash.events.Event;
 
	public class Developer extends Product
	{
		private var staffText:String;
		private var staffImg:String;
		private var url:URLRequest
		private var loader:Loader
		private var fileNow:URLRequest;
		private var txtLoader:URLLoader;
		private var loadCheck:URLLoader;
 
		public function Developer()
		{
			staffText = "text/developer.txt";
			staffImg = "images/developer.png";
 
			loadInfo(staffText);
			loadImg(staffImg);
		}
 
		override protected function loadInfo(txtInfo:String):void
		{
			txtLoader = new URLLoader();
			txtLoader.addEventListener(Event.COMPLETE,nowLoaded);
			fileNow = new URLRequest(txtInfo);
			txtLoader.load(fileNow);
		}
 
		override protected function loadImg(staffImg:String):void
		{
			url = new URLRequest(staffImg);
			loader=new Loader();
			loader.load(url);
			addChild(loader);
			loader.x = 180,loader.y = 131;
		}
	}
}
 
//HCI
package
{
	import flash.net.URLRequest;
	import flash.display.Loader;
	import flash.net.URLRequest;
	import flash.net.URLLoader;
	import flash.display.Sprite;
	import flash.events.Event;
 
	public class HCI extends Product
	{
		private var staffText:String;
		private var staffImg:String;
		private var url:URLRequest
		private var loader:Loader
		private var fileNow:URLRequest;
		private var txtLoader:URLLoader;
		private var loadCheck:URLLoader;
 
		public function HCI()
		{
			staffText = "text/hci.txt";
			staffImg = "images/hci.png";
 
			loadInfo(staffText);
			loadImg(staffImg);
		}
 
		override protected function loadInfo(txtInfo:String):void
		{
			txtLoader = new URLLoader();
			txtLoader.addEventListener(Event.COMPLETE,nowLoaded);
			fileNow = new URLRequest(txtInfo);
			txtLoader.load(fileNow);
		}
 
		override protected function loadImg(staffImg:String):void
		{
			url = new URLRequest(staffImg);
			loader=new Loader();
			loader.load(url);
			addChild(loader);
			loader.x = 180,loader.y = 131;
		}
	}
}

This ends the classes that make up the Factory Method pattern used in this post. They’re available to download. Just click the Download button below and load ‘em up in either Flash Builder or Flash.

Back to Work

As this New Year begins with new problems and opportunities for solving problems, we really need to think about the quality of our work. Down the line somewhere, a program that you helped write with good OOP and design pattern practices may solve someone else’s problem. The program may have one feature that because of what you did made it better. Maybe if we just do a little better for ourselves in terms of program practices, something good will come of it. Then at this time next year, we’ll all be a little better. For me, that’s enough.

Doing the Loosen Up

Few of you remember Archie Bell and the Drells, but their song, Tighten Up was a big hit back in the day. With design patterns, we want to do the opposite, Loosen Up. At this point, we’re going to do the Loosen Up. So put on your dancing shoes and look at the post No New is Good New. The purpose of the post is to get us to think about relationships between objects in a programming design. The dictum, program to an interface and not an implementation is invoked, and the post discusses different kinds of relationships found in design pattern diagrams. If you’re not sure about the issues involved, that post will help understand the next step in introducing design patterns to work.

At this stage in the series, we have arrived at one of the pillars of OOP, inheritance. Figure 1 shows a simple diagram of where we are now in refactoring the original application that used ActionScript on the Timeline.

Figure 1: Inheritance from a parent class

As you saw, inheritance allows developers to use the properties and methods of existing classes and in so doing saves time and adds consistency. However, a standard inheritance model also requires the client to instantiate all of the child classes that must be used. True, the instantiation can be through the parent class by initially typing the objects as the parent class rather than the child class as the following shows:

private var hci:Staff;
hci = new HCI();

The purpose of instantiating the parent is to make the link more general and flexible without breaking encapsulation. If the parent class changes, the objects typed to the parent have a better chance of working well without modification.

As noted in the post about using the new statement, each new statement may limit your flexibility. If a change is made to the object, your Client or some other part of your program may have to be modified to accommodate the change. One way to deal with that is to follow the dictum,

Identify the aspects that vary and separate them from what stays the same

So what varies in the program? That’s easy—the staff does. The Client chooses one of three Staff types (children). So how do we separate them? One solution is the use of a simple factory. Basically, a simple factory separates the Client from the instantiation process. Whatever you want, you ask the simple factory instead of instantiating the requested object. The Client instantiates a single factory object, and the factory object instantiates the objects by the Client. In that way, the Client needs to only instantiate a single object rather than any number made up of the child subclasses. Figure 2 shows this new model:

Figure 2: Adding a Simple Factory

At this point, you may be thinking, finally a design pattern! However, the simple factory is not a design pattern but instead a programming operation or mode. As we will see, the simple factory can be used in a Factory Method design pattern, but it’s also used in the Flyweight pattern. Some of the other operations you will find with design pattern names include singleton, observer and template method. (See pp. 66 to 68 for an introduction to the concepts at work here in the factory. Also, Chapter 9 explains the template method as an operation and a design pattern.)

By focusing on the more specific operation instead of the entire design pattern, we’re better able to clearly see what the operation is up to. If you understand the operations, you can more easily introduce them into the workplace as a simple and useful tool. The important task is create a site with as few locked up relations as possible. Do the Loosen Up.

Separating the Parts that Vary from those that Stay the Same

The Client in the example program has the following operation to select among the available choices:

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

	staffNow = e.target.label.toLowerCase();
	switch (staffNow)
	{
		case "developer" :
			develop = new Developer();
			addChild(develop);
			lastClass = develop;
			break;
		case "designer" :
			design = new Designer();
			addChild(design);
			lastClass = design;
			break;
		case "hci" :
			hci = new HCI();
			addChild(hci);
			lastClass = hci;
			break;
	}

By removing this portion of the code from the Client and moving it to a simple factory class, we can extract just the part where change occurs. The following code shows this new Factory 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
27
28
29

package
{
	import flash.display.Sprite;
 
	public class Factory
	{
		private var design:Staff;
		private var develop:Staff;
		private var hci:Staff;
 
		public function makeStaff(staffNow:String):Sprite
		{
			switch (staffNow)
			{
				case "designer" :
					return ( new Designer() );
					break;
				case "developer" :
					return ( new Developer() );
					break;
				case "hci" :
					return ( new HCI() );
					break;
				default :
					return null;
			}
		}
	}
}

Note that the private variables with the names of the requested objects are also moved to the Factory. The Client no longer needs them because the Factory is going to be doing the instantiation. Now that the changing aspects were removed from the Client class, we’ll change the Client to make the requests from the Factory class.

Before doing that though, note that the makeStaff() method returns a Sprite instead of the class object. Chandima suggested this because you will be able to place it on the stage. Otherwise, you’d have to use a bit more convoluted approach (which I unfortunately mastered) to insure that the graphics and text appear on the page. Now, in looking at the Client, we see only a single Factory instance instantiated instead of three Staff 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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

package
{
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	//Client Class
 
	public class Client extends Sprite
	{
		private var logo:Sprite = new Logo();
		private var splash:Sprite = new Splash();
		private var desBtn:Button = new Button();
		private var devBtn:Button = new Button();
		private var hciBtn:Button = new Button();
		private var staffNow:String;
		private var staffDisplay:Sprite;
		private var factory:Factory=new Factory();
 
		public function Client()
		{
			desBtn.label = "Designer";
			desBtn.addEventListener(MouseEvent.CLICK,selectStaff);
			addChild(desBtn);
			desBtn.x = 424,desBtn.y = 66;
 
			devBtn.label = "Developer";
			devBtn.addEventListener(MouseEvent.CLICK,selectStaff);
			addChild(devBtn);
			devBtn.x = 424,devBtn.y = 116;
 
			hciBtn.label = "HCI";
			hciBtn.addEventListener(MouseEvent.CLICK,selectStaff);
			addChild(hciBtn);
			hciBtn.x = 424,hciBtn.y = 166;
 
			logo.x = 16,logo.y = 16;
			logo.width = 150,logo.height = 121.5;
			addChild(logo);
 
			splash.x = 32,splash.y = 168;
			addChild(splash);
		}
 
		private function selectStaff(e:MouseEvent):void
		{
			splash.visible=false;
 
			staffNow = e.target.label.toLowerCase();
 
			if (staffDisplay)
			{
				removeChild(staffDisplay);
			}
			staffDisplay = factory.makeStaff(staffNow);
 
			addChild(staffDisplay);
		}
	}
}

Now suppose that the Staff and the Staff child classes all change. What’s going to happen to the Client? Nothing. All the Client is requesting and the Factory returning is a Sprite. So the Staff and its children classes can change all they want. The Client needs to change nothing. In addition, the Client only instantiates a single instance; not of the Staff class but of the Factory. The following code is the Staff class and its children.

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

//Staff Class
package
{
	import flash.display.Loader;
	import flash.net.URLRequest;
	import flash.net.URLLoader;
	import flash.display.Sprite;
	import flash.text.TextField;
	import flash.events.Event;
	import flash.text.TextFieldType;
	import flash.text.TextFormat;
 
	//Parent class
	public class Staff extends Sprite
	{
		private var loader:Loader;
		private var url:URLRequest;
		private var fileNow:URLRequest;
		private var txtLoader:URLLoader;
		private var loadCheck:URLLoader;
		private var textField:TextField = new TextField();
		private var textFormat:TextFormat = new TextFormat();
 
		public function Staff()
		{
			textField.type = TextFieldType.DYNAMIC;
			textField.wordWrap = true;
			textField.textColor = 0x007700;
			textFormat.font = "Arial Black";
			textFormat.size = 16;
			textField.defaultTextFormat = textFormat;
		}
 
		protected function loadInfo(txtInfo:String):void
		{
			txtLoader = new URLLoader();
			txtLoader.addEventListener(Event.COMPLETE,nowLoaded);
			fileNow = new URLRequest(txtInfo);
			txtLoader.load(fileNow);
		}
 
		private function nowLoaded(e:Event):void
		{
			loadCheck = URLLoader(e.target);
			textField.text = loadCheck.data;
			textField.width = 200;
			addChild(textField);
			textField.x = 180,textField.y = 331;
		}
 
		protected function loadImg(img:String):void
		{
			url = new URLRequest(img);
			loader=new Loader();
			loader.load(url);
			addChild(loader);
			loader.x = 150,loader.y = 130;
		}
	}
}
 
//Child classes
 
//Designer
package
{
	public class Designer extends Staff
	{
		private var staffText:String;
		private var staffImg:String;
 
		public function Designer()
		{
			staffText = "text/designer.txt";
			staffImg = "images/designer.png";
 
			loadInfo(staffText);
			loadImg(staffImg);
		}
	}
}
 
//Developer
package
{
	public class Developer extends Staff
	{
		private var staffText:String;
		private var staffImg:String;
 
		public function Developer()
		{
			staffText = "text/developer.txt";
			staffImg = "images/developer.png";
 
			loadInfo(staffText);
			loadImg(staffImg);
		}
	}
}
 
//HCI
package
{
	public class HCI extends Staff
	{
		private var staffText:String;
		private var staffImg:String;
 
		public function HCI()
		{
			staffText = "text/hci.txt";
			staffImg = "images/hci.png";
 
			loadInfo(staffText);
			loadImg(staffImg);
		}
	}
}

As you can see, the Staff class and its children are almost identical to the previous incarnations in Part II of this series. The child classes were changed to include private variables and the invocations of the main operations appear far more polymorphic (they’re all identical), but those changes are just cosmetic to reinforce OOP thinking. Also, a subtle but important change is in changing the typing of the logo and splash page to Sprites type in the Client. This provides an opportunity for you to see if you can work out the operations needed to click the logo and have the splash page appear. Of course, you’ll want to move the request to the Factory class, and if you can do this, you probably are well on your way to sneaking in some good OOP and a pre-design pattern mode into the workplace. Click the button to download the entire application:

Playing Nicely in the Sandbox

Several years back a hugely talented artist and I worked together on a project. It began as a mutual admiration relationship and ended in the worse case of angst and misery I can remember. Neither of us liked the other at the end of the project, and the project suffered because of our conflict. To this day I regret the relationship’s destruction. For lack of a better explanation, we had two diametrically opposed ideas of what would best serve the goals of the project and we both assumed that the other was seeking the same goal as we were.

He created animations using Flash and included ActionScript on the Timeline, in buttons, in movie clips and God knows where else. (I don’t think I ever found them all.) Naturally, the Flash app kept growing and the pre-loader I made had to dance the dance of the seven veils to keep the viewer from desperately hammering the Back button. The Library was full of Tween symbols (Tween 1, Tween 2, etc.) that meant something was moved before it was converted to a symbol or some other screw up. Undaunted, the artist soldiered on and eventually created a huge animation that was a wonder to behold. (Of course you could rotate the tires on your car while waiting for the SWF to load.)

The introductory animation was exactly what the clueless project manager had wanted. (I think he said something like, “Dazzle me!”) Unfortunately, after viewing this dazzling behemoth a couple of times, it lost its charm and so as is often the case, the project had a big fat white elephant sitting at the doorstep to be side stepped with a Skip Intro button.

I could go on and on, but the purpose is not to tell tales of woe about non-developers in real world project development. As many of you must know, working in jobs with projects and datelines is more complex than simply putting together good code. For me, the three key elements for a successful Web site are:

• Good graphics (visible)
• Good UI (visible)
• Good Programming (invisible)

Jennifer Tidwell (who rudely completed degrees from both MIT and Massachusetts College of Art just to make the rest of us look bad) found that good graphics were seen as the most trustworthy element of a Web site. So whether we like it or not, we have to have sites with good graphics, and if you’re a developer, assume you have no graphic or artistic skills. (I know of exceptions—like Jennifer—, and if you’re one of them, you don’t need to tell me.) The fact of the matter is we should do everything we can to use our programming skills to ensure that the graphics can be viewed as intended by the artist. Part of that task may be making sure that the artists keep their mitts off the code.

A few years ago I went to an HCI meeting in London. Two things came out of that meeting. First, HCI is essential to a successful Web site. Second, the HCI folks feel that they do not get the respect they deserve. In fact, they feel that they get none at all. UI and navigation needs to be well planned and coded. Coding HCI is like anything else, and it can get seriously complex with a big online business site. Given that design patterns and OOP have their greatest value with large-scale projects that are constantly changing, if you find the right pattern with the UI system, you’ll be a happy developer and so will the HCI folks.

The biggest enemies of good HCI are graphic artists. Seriously. A graphic artist gets tied into looking good and the HCI folks into finding stuff. A few years ago MOMA (New York City’s Museum of Modern Art) had a Web site with a navigation system that looked like a Rubik’s Cube and was about as easy to use. Each block in the cube was an unlabelled trigger and when you clicked on it, you were given a popup telling you what you’ve found. (This occurs shortly before you hit the back button on your browser.) The folks at MOMA probably listened to someone who convinced them that people love to explore Websites. Oddly, the site functioned spiffily which indicated some good code under the hood. So for users who had nothing to do for the rest of their lives, they could explore MOMA’s Rubik navigation system. Since then they discovered that patrons of the arts need to find where they can donate money and art shoppers need to find stuff to buy. If you go to the site now, you’ll see the war between the dancing baloney that makes up the header (unfortunately done in Flash), and the Puritanical UI that allows you to find stuff. (Imagine the discussions that must go on at that site between designers, developers and HCI folks! And you thought you had problems.)

Not Sucking

If you have nothing better to do (and the fact that you’re reading this blog indicates as much), pay a visit to Web Pages that Suck. While the keeper of the site prides himself on being the august voice of good Web sites, his own site suffers from ambiguity. Nevertheless, he has a real knack for identifying bad Web sites, and if you dig around you’ll find some good tips on navigation and making Web sites that work—actually avoiding ones that don’t work. He coined the term Mystery Meat Navigation and his examples of such navigation reinforce the necessity for good HCI people on board your staff. (However, the guy becomes almost apoplectic over Flash, so be forewarned.)

So what does this all have to do bringing a design pattern and good OOP practices to work? Everything! You have to deal realistically with people who have their hands full. Your paycheck and your programming skills are tied to their success. By starting with a few good OOP practices you can work your way to the doorstep of design patterns to improve your code at work. You have to work with designers and HCI folks to create good Website; so be aware of what they must accomplish. By the same token, you need to develop good code to present attractive graphics and for the navigation system to operate smoothly. So while helping others in your workaday mix to accomplish their goals, don’t forget your own.

Getting Off the Timeline

As the readers of this blog are well aware, the Timeline in Flash is a valuable tool for animation. By using the Timeline in conjunction with symbols, IK and tweening, all kinds of wonderful creations are possible. However, the Timeline is not a good place for code, and again, this is nothing new to readers of this blog. So why bring it up?

If you peruse the ActionScript job openings at places like Dice.com and Monster.com, you’ll find openings that include the following requirements:

The successful candidate should have at least three years experience using ActionScript 2.0 with knowledge of ActionScript 3.0 a plus. He/she should also have the ability to maintain and update legacy Flash sites with ActionScript 1.0. A knowledge of OO programming and design patterns is strongly desirable.

Work that includes maintaining a site written in ActionScript 1.0 (and even ActionScript 2.0 in some cases) almost certainly means that some or all of the code is written on the Timeline and possibly even embedded in the individual symbols —buttons and movie clips. In other words, a good deal of the work is playing Where’s Waldo? with the ActionScript scattered all over the place. For me, working to maintain such a site is somewhere south of Dante’s 9th Circle of Hell. (You remember Dante’s Divine Comedy from that humanities class you had to take.)

In Part I of this post series, the code is embedded in an ActionScript layer on the Timeline. Maintaining the site is pretty simple both in making changes and adding new materials. The developer makes changes by changing the image file and the text contents in any single keyframe. Additions are made by adding keyframes in the Options layer, code in the ActionScript layer and buttons in the Buttons layer. That’s not a difficult plan. So why change?

With a relatively small staff in the company, there’s probably no reason to change it at all. However, as the staff grows or they want to add more to the site, especially in terms of additional graphics and animated materials, the size of the SWF file grows as well. Pretty soon, you’re making pre-loaders, and that’s a good sign that you’re in trouble.

In addition to the problems in generating a big fat SWF file, a single set of ActionScript statements can only grow into a larger and less manageable set of code. For a small application, it works fine, but as applications grow, unless some of the inherent problems are addressed, an error prone application begins to emerge. Change becomes more problematic and the program begins to lose functionality as well as flexibility.

The Client and the Request

A good place to start is with the Client class. (I’m going to capitalize Client where I’m referring to the Client as a class. Non-cap client refers to all other uses of the term such as client-server or Our client wanted us to develop a flexible application.) The Client is the gimme class–“Gimme this! Gimme that!”—in non-idiomatic English, that would be “Give me this! Give me that!” It makes requests from the set of classes that make up the design pattern. Since we haven’t got a design pattern at this point, think of the Client as the class we need for making requests. Also, as a general concept, think of the Client as making requests from other classes. That is, instead of making requests from itself, while possible from a self-contained function, the Client has a reference to another class or interface.

Some design patterns provide the position of the Client in the class diagram and others do not. For example, on pages 66-67 of ActionScript 3.0 Design Patterns, you can see the Client class in the diagram in both the Simple Factory Method and the Factory Method design pattern, but on page 131, you see no Client class in the Decorator design pattern. That doesn’t mean you’re not going to use a Client class. It simply means your Client class will make its requests from the pattern but is not implied or part of the pattern itself. Patterns with implied Clients such as the Proxy pattern display the Client ghosted or faded. Otherwise, a visible Client in a class diagram means that the Client is part of the design pattern. About half the design patterns show the Client as part of the pattern or implied. An implied connection means that means the Client is expected to have a connection between itself and a specific class in the pattern but is not part of the pattern’s structure. Sometimes, a Client is displayed with relations to more than a single other class in the pattern. One example is the Interpreter pattern.

The Request for an Object

The Client makes a request from another class that has built the desired content. This may be an object or process. A simple example would be to request a graphic image that was created in an image class. In the example from Part I of Bring a Design Pattern to Work, the request is in the form of buttons serving as UIs. Each button requests a different Staff page. In essence the request is to go to and stop at a specified keyframe. So, let’s take the ActionScript off the Timeline and create a Client class and object classes for the three staff members. The Client requests one of three staff members; so all we need to do is to create three Staff classes. The Client can create its own request UIs using Button components (which in themselves are classes.)

We can imagine several different strategies to request the three classes with images and text. First, we could create three SWF files, each with a different staff member with image and text. That’s pretty easy in Flash and Flex. Just slap the graphic and text right on a black background that’s that. Figure 1 shows the setup for a Flex application. After saving and testing the application, you can use the automatically generated SWF file in Flash or Flex. Of course you’d have to create some kind of loader to place the SWF files where you want them, but it would work just fine.

Figure 1: Creating SWF file in Flex

Using your imagination, you can think of lots more ways that a Client could request an image with a text caption and how to set up the image and text that will be requested. If your customer wants to make changes on her own without having to know a thing about Flash or Flex, then the process for the developer becomes a little tougher. You’d need a way to load image and text files independently and place them on the stage. The customer could just change the contents of the images and text for staff changes. If more staff members are added, the developer would have to go in and add more requests (buttons) to the Client and somehow fix the Object class to accept more images and text captions. Figure 2 diagrams the Client making requests directly to each class.

Figure 2: Client making requests from each class

Each of the Staff classes can then load up the necessary image and text. Adding new staff is simple. Just copy and paste any of the classes and change the image and text targets for the class. The following pseudo-code shows what each staff class looks like:

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

//NOTE: This is pseudo-code. It does not work.
package
{
          import.Sprite;
          import.ClassesForLoaders;
          import.ClassesForText;
 
          public class StaffX extends Sprite
          {
                    public function StaffX()
                    {
                              //Text field and its properties
                              new TextField();
                    }
 
             //Method for loading image
             public function loadImage(from Client):void
             {
                         loader.load(from Client);
              }
 
              //Method for loading text
 	      public function loadText(from Client)
              {
                         urlLoader.load(from Client);
               }
          }
}

Inheritance

If you stop and think about this for a second, you realize that if all of the staff classes are pretty similar in their functionality, why not just create a parent class and instantiate the other classes as inheriting a parent class? As each new child class is added, all you’d need to do is to use a loading method inherited from the parent class. Then each Staff class could be just a pair of loading methods that load the requested materials. Figure 3 shows a diagram of this new arrangement:

Figure 3: Client making requests through parent class

After all, we know that inheritance is one of the cornerstones of OOP, and in looking at Figure 3. It sure looks like good OOP. That’s as good a place to start with introducing OOP concepts (inheritance) as anywhere.

Client Jobs

Because the focal chore of the Client class is to make requests, it may seem either trivial or marginal to give it more than a cursory glance. However, as you will see in this series of posts, it can be crucial. So let’s pay the Client its due.

The request UI in the first post of this series was the Button component, and we’ll continue using that UI. The requests change only slightly. Instead of the requesting the playhead to move to and stop at a particular keyframe, this time the Client requests a class representing one of three staff positions. So the buttons with their attending events and event-handlers are all part of the Client class.

In addition to making requests, the Client has some setup chores. It places a logo and a ‘splash’ page on the stage. Both are made up of movie clip objects in the Library. The logo stays on the stage, but as soon as the photos and text from the staff begin to appear, the splash page disappears. That’s it for the logo and splash page.

Keeping in mind that this application uses subclasses, the first practice to keep in mind is:

Program to an interface; not an implementation

At this point, the parent class (Staff) is a pretty static interface, but for the sake of good practices go for a looser typing when possible. The child classes, Designer, Developer, and HCI, are implementations; so we’ll treat the parent class as an interface.*

*Note: Both interfaces and abstract classes are considered interfaces. I am well aware that ActionScript 3.0 does not have abstract classes, but the concept of an interface here is not the ActionScript statement, interface, but instead it refers to the more general idea of a supertype. See pp. 45-49 of our book for more details. Also, the Freemans have a great explanation of the concept on page 12 of Head First Design Patterns.

Thus, in declaring the private variables for the different subclasses of the Staff class, they are typed as Staff. It’s a looser kind of typing even though at this stage of the game, it’s not a whole lot looser given the very static nature of the child classes emerging from the parent class Staff.

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

package
{
          import flash.display.Sprite;
          import fl.controls.Button;
          import flash.events.MouseEvent;
 
          //Client Class
          public class Client extends Sprite
          {
                    private var logo:Logo=new Logo();
                    private var splash:Splash=new Splash();
                    private var design:Staff;
                    private var develop:Staff;
                    private var hci:Staff;
                    private var lastClass:Staff;
                    private var desBtn:Button=new Button();
                    private var devBtn:Button=new Button();
                    private var hciBtn:Button=new Button();
                    private var staffNow:String;
 
                    public function Client()
                    {
                             //Add the buttons to provide a UI for the requests
                              desBtn.label = "Designer";
                              desBtn.addEventListener(MouseEvent.CLICK, selectStaff);
                              addChild(desBtn);
                              desBtn.x = 424,desBtn.y = 66;
 
                              devBtn.label = "Developer";
                              devBtn.addEventListener(MouseEvent.CLICK, selectStaff);
                              addChild(devBtn);
                              devBtn.x = 424,devBtn.y = 116;
 
                              hciBtn.label = "HCI";
                              hciBtn.addEventListener(MouseEvent.CLICK, selectStaff);
                              addChild(hciBtn);
                              hciBtn.x = 424,hciBtn.y = 166;
 
                             //Place the logo and splash page on the stage
                              logo.x = 16,logo.y = 16;
                              logo.width = 150,logo.height = 121.5;
                              addChild(logo);
 
                              splash.x = 32,splash.y = 168;
                              addChild(splash);
                    }
 
                    //Client request list
                    private function selectStaff(e:MouseEvent)
                    {
                              //Remove the initial text block (in a movie clip)
                              splash.visible=false;
 
                              //Remove previous image and text
                              if (lastClass)
                              {
                                        removeChild(lastClass);
                              }
 
                     //Change the button labels to lowercase
                      staffNow = e.target.label.toLowerCase();
 
                      //Use the switch statement to sort our the requests
                              switch (staffNow)
                              {
                                        case "developer" :
                                                  develop = new Developer();
                                                  addChild(develop);
                                                  lastClass = develop;
                                                  break;
                                        case "designer" :
                                                  design = new Designer();
                                                  addChild(design);
                                                  lastClass = design;
                                                  break;
                                        case "hci" :
                                                  hci = new HCI();
                                                  addChild(hci);
                                                  lastClass = hci;
                                                  break;
                              }
                    }
          }
}

Normally you would not name your Client class, “Client,” but instead you’d provide something more descriptive. However, because this is an exercise to clearly identify the different parts that make up a design pattern, it is helpful to do so here.

The Parent Class

Often in design patterns you’ll have more than a single parent class, but in this OOP pattern, all we’re using the single parent class for is to illustrate inheritance. This particular parent class is very handy because it creates a text field, loads external text in and then load in a graphic or SWF file. (What’s not to like!). Then, we’ll subclass all the child classes that will use it.

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

package
{
          import flash.display.Loader;
          import flash.net.URLRequest;
          import flash.net.URLLoader;
          import flash.display.Sprite;
          import flash.text.TextField;
          import flash.events.Event;
          import flash.text.TextFieldType;
          import flash.text.TextFormat;
 
          //Parent class
          public class Staff extends Sprite
          {
                    private var loader:Loader;
                    private var url:URLRequest;
                    private var fileNow:URLRequest;
                    private var txtLoader:URLLoader;
                    private var loadCheck:URLLoader;
                    private var textField:TextField = new TextField();
                    private  var textFormat:TextFormat = new TextFormat();
 
                    public function Staff()
                    {
                              //Set up text field and text format
                              textField.type = TextFieldType.DYNAMIC;
                              textField.wordWrap = true;
                              textField.textColor = 0x007700;
                              textFormat.font = "Arial Black";
                              textFormat.size = 16;
                              textField.defaultTextFormat = textFormat;
                    }
 
                    //Load the external text
                    protected function loadInfo(txtInfo:String):void
                    {
                              txtLoader = new URLLoader();
                              txtLoader.addEventListener(Event.COMPLETE,nowLoaded);
                              fileNow = new URLRequest(txtInfo);
                              txtLoader.load(fileNow);
                    }
 
                    //Place loaded text into text field
                    private function nowLoaded(e:Event):void
                    {
                              loadCheck = URLLoader(e.target);
                              textField.text = loadCheck.data;
                              textField.width=200;
                              addChild(textField);
                              textField.x = 180,textField.y = 331;
                    }
 
                    //Load the graphic image or SWF file
                    protected function loadImg(img:String):void
                    {
                              url = new URLRequest(img);
                              loader=new Loader();
                              loader.load(url);
                              addChild(loader);
                              loader.x = 150,loader.y=130;
                    }
          }
}

Note that most of the methods are protected, and one is private. As usual, the constructor is public. The protected methods are such so that they have some encapsulation and yet can be used by children of the parent class.

All the Little Kiddie Classes

Now that the Client and main parent class is ready, the target of the requests can be built. These have been stripped down to illustrate how simple it is to use inheritance to get what you need. At this point the site only needs three children classes, one each for the different departments:

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

//Designers
package
{
          public class Designer extends Staff
          {
                    public function Designer()
                    {
                              loadInfo("text/designer.txt");
                              loadImg("images/designer.png");
                    }
          }
}
 
//Developers
package
{
          public class Developer extends Staff
          {
                    public function Developer()
                    {
                              loadInfo("text/developer.txt");
                              loadImg("images/developer.png");
                    }
          }
}
 
//HCI Folks
package
{
          public class HCI extends Staff
          {
                    public function HCI()
                    {
                              loadInfo("text/hci.txt");
                              loadImg("images/hci.png");
                    }
          }
}

The only remaining chore is to place the text files and image files in the text and images folders. The original request from the Client class is simplified by using Button components and their labels to identify the desired staff. If you’d rather not have a big conditional switch statement, you can make each button have a different event handler. You can view the application here and download the application here.

When you test your application, you should see pretty much the same thing that you saw with the original application. None of the code is on the Timeline, and all the customer has to change is the content of the text and images in the folders to change what the viewer will see. Figure 4 shows what you can expect to see when you test the application.

Figure 4: Delivered request

If you review the first post of this series you’ll see similarities and differences. The buttons in Figre 4 pick up the background color, and the logo has a better gradient in the sun behind the Sandlight text.

More Help on the Way

At this point, you’ve seen the progression from legacy ActionScript stuck on a Timeline to using OOP. By thinking about loosening up an application, you’re beginning to think about a flexible program where change and update are easier. If you look at your programs at work in this way, you can begin to think of how they can be made stronger and more flexible at the same time. In the next installment, we’ll take the penultimate step on the way to a design pattern for this application.