Think in Non-Linear Concepts

Other than the fact that nested conditionals can create the worst kind of object binding as each condition sends the program further down the binding rabbit hole, we seem to really need them for working out certain kinds of problems. For example, in a visual game scenario, the user may be faced with choices. Suppose the game state is a crossroad where the player must choose to go North, East, West or South (NEWS). Alternatively, the choice may be video perspectives of different directions. Any one of the choices carries with it a whole set of other states, conditions, capabilities and properties.

One way to handle this kind of choice is with a conditional statement. The following shows two things. First, it shows that when a direction is selected, it typically has more than one thing being affected. (The more than one thing is furnished by “Everything else.”) Second, the binding for each is represented by the conditions within each conditional. (You could do the same thing with a Switch statement, but the binding wouldn’t change.)

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

package
{
	import flash.display.Sprite;
	public class NEWS extends Sprite
	{
		private var newsArray:Array = new Array("north","east","west","south");
		private var dir:Object;
 
		public function NEWS()
		{
			for (dir in newsArray)
			{
				if(newsArray[dir]=="north")
				{
					trace("Hellloo Siberia");
					trace("Everything else....");
					trace("");
				}
				else if(newsArray[dir]=="east")
				{
					trace("Visiting Bejing");
					trace("Everything else....");
					trace("");
				}
				else if(newsArray[dir]=="west")
				{
					trace("Dude! You made it!");
					trace("Everything else....");
					trace("");
				}
				else if(newsArray[dir]=="south")
				{
					trace("¡Recepción a la Argentina!");
					trace("Everything else....");
					trace("");
				}
			}
		}
	}
}

That certainly can solve the issue of generating different responses from different object properties. It’s compact and saves ground-fills of wasted bits. It illustrates a common method of dealing with multiple options. The loop iterates through the object, and each iteration is examined by four conditional statements.

Unconditional Programming

Let’s go back to the NEWS example, and instead of having trace statements representing different directions, this next example uses short videos pointing in different directions. (I live in the woods so the videos are fairly woodsy—but they show the four points of the compass—honest.) I want to make an app with four buttons that plays a video pointing in the selected direction. Plus, I don’t want to use any conditional statements. (Easier than you think.) Click the Play and Download buttons to see a working example and get the code and videos.

In the next section where we examine the code you will see two things: No conditional statements and a non-linear solution. The user has several choices, and simply by making a choice she/he goes directly to the object desired—a directional video.

The Client, the UI and Requests

Like any good Client class, this client takes care of the UI and makes requests from other classes. Most of it is just providing a non-conditonal and non-linear solution.

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

package
{
	import fl.controls.Button;
	import flash.display.Sprite;
	import flash.events.MouseEvent;
 
	public class Client extends Sprite
	{
		private var dummy:Sprite=new Sprite();
		private var nBtn:Button=new Button();
		private var eBtn:Button=new Button();
		private var wBtn:Button=new Button();
		private var sBtn:Button=new Button();
		private var north:North;
		private var east:East;
		private var west:West;
		private var south:South;
 
		public function Client()
		{
			nBtn.addEventListener(MouseEvent.CLICK,goNorth);
			nBtn.width=70;
			nBtn.x=(550/2)-(nBtn.width/2),nBtn.y=10;
			nBtn.label = "North";
			addChild(nBtn);
 
			eBtn.addEventListener(MouseEvent.CLICK,goEast);
			eBtn.width=70;
			eBtn.x=550-(eBtn.width+5),eBtn.y=210;
			eBtn.label = "East";
			addChild(eBtn);
 
			wBtn.addEventListener(MouseEvent.CLICK,goWest);
			wBtn.width=70;
			wBtn.x = 5,wBtn.y = 210;
			wBtn.label = "West";
			addChild(wBtn);
 
			sBtn.addEventListener(MouseEvent.CLICK,goSouth);
			sBtn.width=70;
			sBtn.x=(550/2)-(sBtn.width/2),sBtn.y=370;
			sBtn.label = "South";
			addChild(sBtn);
		}
 
		private function goNorth(e:MouseEvent)
		{
			north=new North();
			addChild(north);
		}
 
		private function goEast(e:MouseEvent)
		{
			east=new East();
			addChild(east);
		}
 
		private function goWest(e:MouseEvent)
		{
			west=new West();
			addChild(west);
		}
 
		private function goSouth(e:MouseEvent)
		{
			south=new South();
			addChild(south);
		}
	}
}

As you can see from the Client and testing the app, the Client just fires a function that calls one of four classes that run a video. The user makes requests through the buttons that fire methods that call classes. These classes contain what’s required for each of the four states. We’ll use North as a generic example. (The other three classes are identical except for the name of the video they call.)

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

package
{
	import flash.net.NetConnection;
	import flash.net.NetStream;
	import flash.display.Sprite;
	import flash.media.Video;
	import flash.events.NetStatusEvent;
 
	public class North extends Sprite
	{
		private var nc:NetConnection = new NetConnection();
		private var ns:NetStream;
		private var vid:Video=new Video();
		private var hookup:Boolean;
		private var dir:String="north.f4v";
		private var sniffer:Object=new Object();
 
		public function North()
		{
			nc.addEventListener(NetStatusEvent.NET_STATUS,doConnect);
			nc.connect(null);
			vid.x=137.5, vid.y=80;
		}
 
		private function doConnect(e:NetStatusEvent):void
		{
			hookup=(e.info.code=="NetConnection.Connect.Success");
			if (hookup)
			{
				ns=new NetStream(nc);
				ns.client=sniffer;
				sniffer.onMetaData=getMeta;
				vid.attachNetStream(ns);
				ns.play(dir);
				addChild(vid);
			}
		}
		private function getMeta (mdata:Object):void
		{
			//Use if metadata required
		}
	}
}

The sharp-eyed among you will have spotted the conditional statement. It is fired by the NetConnection.Connect method and is more of a good practice than anything else. I could probably get away without it given that the videos are so small and load quickly; however, it is a good practice to check to make sure that a video is connected. So rather than trying to prove a point at the expense of a good practice, I’ll allow this one conditional to check connections and preserve a good practice. (I’ll also be tracking down another way to do the same thing without a conditional.)

You may be thinking that you could do the whole thing in the Client class by stuffing all the required methods and properties into the Client. You’d be right. In fact, while you’re at it you could stuff improvements in error checking and remove each video as a new one was played. However, as you put more and more into a class, you cease to delegate and continue to bind. Re-use and change becomes difficult because the less delegation you use, the more dependencies you stack up.

Next week, we’ll see how to refactor this set of classes into a state machine and a State design pattern. The State design pattern has a magic Context participant and other features that you’ll enjoy when you begin to abandon linear thinking and give OOP thinking a go.

Lazy Bones

There’re more ways than one for being lazy with design patterns. In this post we’ll look at two: First we’ll see where you can take a program based on the Factory Method and reuse it for another program. Secondly, we’ll see where we put lazy instantiation in a Factory Method. That’s double lazy! So Homer Simpsons of the world unite! This is the design pattern for you. D’oh! (In the past we’ve examined lazy initialization, but in this post we’ll look at lazy instantiation.)

Last week we had our first online presentation thanks to the Adobe users in Brazil. However, many missed it, and I promised to provide everyone with the materials we covered. Besides, since this is a discussion of a Factory pattern we can reuse our Factory Button! (Even this post is lazy!) Click the two buttons to see the apps with two different implementations. Then you can download the two apps and the PowerPoint file from the presentation by clicking the download button.

Southern Brazil

New England

So you may be thinking that both of the applications are doing pretty much the same thing—placing objects on the screen. That’s true. Rocket science it’s not. However, the nature of the classes is such that we have a wide range of options with the objects. As the applications are currently laid out, it’s easy to change the objects and the collection of objects without breaking the application. Let’s see how.

Talk to the Factory

The Factory Method design pattern is made up of a Creator (Factory) interface with concrete creators that instantiate concrete products represening implementations of a Product interface. The Creator contains an abstract FactoryMethod() operation that each concrete creator implements. Figure 1 shows a typical factory pattern with different shapes implied from the concrete creators and products. The shapes are representatives of any objects that the developer wants to request using the FactoryMethod() operations.

Figure 1: Factory Method Class Diagram

The class diagram accurately portrays the role of the concrete factories—they instantiate the products indicated by the dashed arrows. The factories are more like car dealerships than they are “factories.” The dealerships order (instantiate) a completely built car. They don’t build them—they get them. If you have parameterized products; then perhaps you can think of the instantiation process as one where the objects are “built” by the concrete factories that pass the arguments, but in this example, think of the concrete creator (factory) classes as “auto dealerships” and not “auto factories.”

Figure 2 shows how the client makes its request and the links between the participants:

Figure 2: Client makes request

To get a better idea of the details of the client’s request, look at Figure 3. The object being requested is a Brazillian state named Paraná (not to be confused with the fish, piranha or paraña). Note that the variable named pirana is typed as a Factory—the interface. Then the request is made by instantiating a concrete factory class, MakeParana, an implementation of the Factory abstract class. (Programming to the interface; not the implementation.)

Figure 3: Client makes request using a Factory object

To help get a better idea of how that request is made in the larger context of a Factory Method design pattern, Figure 4 shows just those classes involved in the request in a file diagram. The request is sent to the MakePirana concrete factory through the Factory interface (an abstract class). The factory instantiates a concrete Product instance named Pirana.

Figure 4: Files used in Pirana object request

If I wanted to change the character of the Pirana object to something else, the Client could care less. It just makes the request to the concrete factory object and lets the factory worry about instantiating the object. Let’s say that instead of the state of Pirana, I wanted to use the design pattern to get the state of Connecticut. I wouldn’t change the request to the factory; I’d change the object that the factory instantiates and returns to the Client.

The Abstract Factory and Product

Both of the interfaces in this implementation of the Factory Method are made up of abstract classes. The Factory class holds a reference to the Product class and an abstract factoryMethod() operation. The details of the factoryMethod() are left up to the concrete factories to implement. Figure 5 shows the Factory abstract class:

Figure 5: The Factory Interface (abstract class)

Nothing is declared and the protected variable, product is only declared as a Product type. Product, is an abstract class and so the product variable will have to be instantiated as a concrete implementation of Product and not Product itself. (You cannot instantiate an abstract class.)

The Product class is similar in that it is abstract and nothing is implemented. Figure 6 shows how it is built:

Figure 6: The abstract class Product

Originally, I had the Product class subclass Sprite, but I realized later that I did not need to do that. Each of the product objects were already children of the Sprite class, and so I had all of the properties and methods in the Sprite class I needed. By not subclassing the Sprite, the Product class is looser because it has no binding through subclassing. Importing the Sprite package is enough to reference the Sprite as the return type of the getObject() method and objectNow property.

Implementing the Concrete Factories (with Lazy Instantiation) and Products

All that’s left is to implement are the Factory and Product interfaces (abstract classes). The objects that are used to actually show images on the screen are Library Sprites. I just drew the different states (estados) using Flash tools and converted them into MovieClip symbols. Then, I converted the MovieClip classes into Sprite classes by changing the Base class from flash.display.MovieClip to flash.display.Sprite.

The concrete factory that calls the requested Parana state, checks to see if the product already exists, and if not, produces one. Then, using the product object it uses the getObject() method to get the requested product. Figure 7 shows how each of the concrete factories are coded–the only difference being that they instantiated different concrete products:

Figure 7: Concrete factory instantiates requested object

We can see the lazy instantiation in the conditional statement that is looking for an uninstantiated product, and if the product does not exist as an instance, it creates one. The product property is inherited from the Factory abstract class. The product is initialized in the Factory class as a Product type—that’s why you don’t see any data type assigned to the product in the concrete factory. So while the product is unimplemented, it has been initialized. This binds the product only to the Product interface and not any single product implementation. As a result, the product object can be used to instantiate any of the concrete properties. This is what makes programming to the interface and loose coupling so valuable.

Finally, we come to the concrete products. Each products extends the Product class and implements the getObject() function. The objNow property (inherited from the Product abstract class) instantiates a Sprite object from the Library. The Sprite can come from any source where a Sprite can be stored. The important fact is that the object is a Sprite and has key Sprite properties and methods. In this case, all we need are the horizontal (x) and vertical (y) properties. Figure 8 shows how the Parana product is created;

Figure 8: Concrete Product class

The important features of this example lies not what was done initially, but rather how it was reused to create a similar application for a different region. Likewise, the concrete factory and product classes follow the OOP single responsibility principle—each has a single responsibility that is loosely bound and re-useable. For example, the following two classes show how the same application was reused to create the New England version of the same 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
26
27
28
29
30
31
32

//Connecticut Factory
package
{
	import flash.display.Sprite;
 
	public class MakeConn extends Factory
	{
		public override function factoryMethod():Sprite
		{
			if(! product)
			{
				product=new ConnProd();
			}
			return product.getObject();
		}
	}
}
 
//Connecticut Product
package
{
	import flash.display.Sprite;
	public class ConnProd extends Product
	{
		public override function getObject():Sprite
		{
			objNow=new Conn();
			objNow.x=188.45, objNow.y=321.75;
			return objNow;
		}
	}
}

As you can see, the concrete factory and product are the same as those for the Brazilian states. The Factory and Product abstract classes are identical.

One Year of Programming Experience 20 times

You may have heard programmers proclaim,

I’ve been programming for 20 years, blah, blah, blah….

While such programmers may have a wealth of knowledge from their experience, they may have just been doing the same kind of programming for 20 years. Years ago, I heard a police officer remark about one of the older (and not too effective) officers as a

…guy who had 1 year experience 20 times.

Essentially the police officer who made that comment was saying that the old-timer never tried to keep up his skill levels with new knowledge. He just kept doing the same old thing again and again. That can happen at any age, and in computing, it’s a recipe for disaster.

When I discovered OOP and then Design Patterns, I realized that I had been like that old cop who kept doing the same thing over and over again. To be sure, I learned several new languages ranging from machine/assembly languages to high level languages like BASIC and even PostScript—and just about everything in between. However, while different computer languages have different lexicons, sequential and procedural programming are still S&P programming no matter what language you’re in.

To break those (bad) habits, design patterns and the OOP that goes with them, forced me to think in different ways approaching programming problems. Instead of thinking in terms of a series of steps, I started to think in terms of loosely bound objects communicating with one another. The only sequences were little ones inside the methods and assigned values to properties—and many of those were just for using other objects. The design patterns themselves became “cheat sheets” where I could more easily envision how objects could be arranged to communicate and achieve a goal.

This particular example somehow brought many of the lessons I’ve learned from design patterns home. It wasn’t until the last minute that I decided to make another regional map where I could demonstrate re-use of design patterns (Southern Brazil to Northeast US). Because I waited until the last minute, that was about all the time I had—that last minute. However, once I finished the graphic sprites, everything else fell into place. I just re-used the structures and the communication systems from the original app. It may sound funny to voice it, but programming to the interface really saved my bacon. Here I had a whole new set of objects I had to get singing in the same choir, but I knew that as long as I paid attention to the interface, everything would work together—that’s 27 classes scaled down to 17 for a new application.(That’s not even counting the Sprite classes with the graphics!) And everything worked out fine.

Try doing that without a design pattern. Spaghetti city!

Take This One to Work

Figure 1: Factory Method with Single Concrete Creator

You can see the design similarities between this application (MrFace) and the Dragon application. The main difference is that this one has a single concrete factory (FaceCreator) for all of the concrete products. The factory churns out all of the Product children and puts them into an array. The Client requests the array from the Creator and pulls out the elements with a loop. As you can see, they’re all draggable elements. Try out the embedded SWF file below to see how it works:

[swfobj src="http://www.as3dp.com/wp-content/uploads/2009/12/Client1.swf" alt="MrFace" align="none"]

The same Product (from the Dragon application) is re-used so it is unnecessary to revise it. However, instead of a video and a dynamically generated graphic, all of the graphics were put into the Library as Sprite classes. (To make a Sprite class just change the Base class to flash.display.Sprite.)

The Abstract and Concrete Factories

Because the main difference between this application and the Dragon app is the way in which the factory classes (Creator and FaceCreator) handle products, we’ll start with them. First, the Creator class provides the necessary interface as shown in the following listing:

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

package
{
	//Mr Face App
	//Asbstract class--serves as interface
	//Creator
 
	import flash.errors.IllegalOperationError;
 
	public class Creator
	{
		private var dragNow:Array;
 
		public function createDragable():Array
		{
			dragNow=getDragon();
			return dragNow;
		}
 
		// ABSTRACT Method (must be overridden in a subclass)
		protected function getDragon():Array
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
			return null;
		}
	}
}

If you’re thinking, That looks a lot like the Creator class for the Dragon application, you’d be absolutely right. In fact, the only difference is that this Creator returns an Array object instead of a Sprite. That’s the purpose of re-use.

The big change is in the way the ConcreteCreator (FaceCreator) works in this design pattern. The abstract function is getDragon(), and so it has to be overridden and set up to instantiate each of the Product children (facial parts) and stuff them into an array. That array is then returned when requested by the Client.

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

package
{
	//Concrete Factory
 
	import flash.errors.IllegalOperationError;
 
	public class FaceCreator extends Creator
	{
		private var faceOn:Array=[];
 
		override protected function getDragon():Array
		{
			var ears:Product=new Ears();
			faceOn.push(ears);
 
			var ears2:Product=new Ears();
			faceOn.push(ears2);
 
			var glasses:Product=new Glasses();
			faceOn.push(glasses);
 
			var nose:Product=new Nose();
			faceOn.push(nose);
 
			var eyes:Product=new Eyes();
			faceOn.push(eyes);
 
			var mouth:Product=new Mouth();
			faceOn.push(mouth);
 
			var hair:Product=new Hair();
			faceOn.push(hair);
 
			var head:Product=new Head();
			faceOn.push(head);
 
			return faceOn;
		}
	}
}

By using an array, the Client only has to request a single object rather than all of the Product children individually as was the case in the Dragon application. That’s it as far as the factory classes are concerned. Next, in looking at the Product and its children classes, you will see that not much has changed from the original designs.

The Product and Its Brood

First of all, take a look at the Product class used as an interface for all of the children classes. Again, the Product is an abstract class instead of an Interface, and it re-uses the same methods and properties.

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

package
{
	//Abstract class--serves as interface
	import flash.display.Sprite;
	import flash.events.MouseEvent;
	import flash.errors.IllegalOperationError;
 
	public class Product extends Sprite
	{
		protected var base:Sprite=new Sprite();
 
		// ABSTRACT Method
		protected function placeParts(lr:uint,ud:uint):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		protected function setPart(part:Sprite):void
		{
			addChild(base);
			base.addChild(part);
			base.addEventListener(MouseEvent.MOUSE_DOWN,dragPart);
			base.addEventListener(MouseEvent.MOUSE_UP,dropPart);
		}
 
		protected function dragPart(e:MouseEvent):void
		{
			this.startDrag();
		}
 
		protected function dropPart(e:MouseEvent):void
		{
			this.stopDrag();
		}
	}
}

There’s nothing new from the original in that Product class; so let’s move on to the concrete elements of the Product. The setup for this used Sprite classes stored in the Flash Library. (Creating a similar Library in Flash Builder should not be too difficult.) The setPart() method does most of the work, and the placeParts() method is overridden just to have an abstract method. (That was to demonstrate flexibility more than it was an essential function to override.)

Given that the abstract Product class is a workhorse, the child classes need only to call the Sprite class out of the Library. All Sprite classes end with a capital “S” to differentiate them from the Product subclasses themselves. For example, the Mouth class instantiates a MouthS class from the Library. Each of the face parts is a small subclass, and so all of them are placed together in the following listing:

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

package
{
	//Concrete Product
	import flash.display.Sprite;
 
	public class Ears extends Product
	{
		private var ears:Sprite = new EarS();
 
		public function Ears()
		{
			setPart(ears);
			placeParts(100,100);
		}
 
		override protected function placeParts(lr:uint,ud:uint):void
		{
			base.x=lr,base.y=ud;
		}
	}
}
 
//
 
package
{
	//Concrete Product
	import flash.display.Sprite;
 
	public class Eyes extends Product
	{
		private var eyes:Sprite = new EyesS();
 
		public function Eyes()
		{
			setPart(eyes);
			placeParts(100,150);
		}
 
		override protected function placeParts(lr:uint,ud:uint):void
		{
			base.x=lr,base.y=ud;
		}
	}
}
 
//
 
package
{
	//Concrete Product
	import flash.display.Sprite;
 
	public class Glasses extends Product
	{
		private var glasses:Sprite = new GlassesS();
 
		public function Glasses()
		{
			setPart(glasses);
			placeParts(80,170);
		}
 
		override protected function placeParts(lr:uint,ud:uint):void
		{
			base.x=lr,base.y=ud;
		}
	}
}
 
//
 
package
{
	//Concrete Product
	import flash.display.Sprite;
 
	public class Hair extends Product
	{
		private var hair:Sprite = new HairS();
 
		public function Hair()
		{
			setPart(hair);
			placeParts(100,200);
		}
 
		override protected function placeParts(lr:uint,ud:uint):void
		{
			base.x=lr,base.y=ud;
		}
	}
}
 
//
 
package
{
	//Concrete Product
	import flash.display.Sprite;
 
	public class Head extends Product
	{
		private var head:Sprite = new HeadS();
 
		public function Head()
		{
			setPart(head);
			placeParts(120,150);
		}
 
		override protected function placeParts(lr:uint,ud:uint):void
		{
			base.x=lr,base.y=ud;
		}
	}
}
 
//
 
package
{
	//Concrete Product
	import flash.display.Sprite;
 
	public class Mouth extends Product
	{
		private var mouth:Sprite = new MouthS();
 
		public function Mouth()
		{
			setPart(mouth);
			placeParts(100,200);
		}
 
		override protected function placeParts(lr:uint,ud:uint):void
		{
			base.x=lr,base.y=ud;
		}
	}
}

Using Flash Builder (Flex), just place the different graphic elements into separate classes using the same Library class names. Just be sure to subclass them from a Sprite.

The Lazy Client

I’ve come to believe that the less the client has to do, the better. That’s because the Client really should do nothing more than make requests. In some designs the Client is actually part of the design and has more to do. However, as a rule of thumb, the Client should only make requests and place elements on the DisplayList. In this application, that’s all the Client does as you can see in the following listing:

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

package
{
	import flash.display.Sprite;
 
	public class Client extends Sprite
	{
		private var faceParts:Array=[];
		private var myFace:Creator=new FaceCreator();
 
		public function Client()
		{
			faceParts=myFace.createDragable();
			var saveFace:uint=faceParts.length-1;
 
			for (var count:uint =0; count <=saveFace; count++)
			{
				addChild(faceParts.pop());
			}
		}
	}
}

As you can see, the Client just requests the Array from the Creator and then sorts out the array. Now that’s not a lot to do!

Stupid dog tricks: #1 and #2. Just in case you wondered, you can instantiate an array by using aName:Array=[] instead of aName:Array= new Array(). You can do the same thing with an Object using oName:Object={}. Maybe it isn’t as clear as spelling out the object name, but we’re all entitled to a few stupid dog tricks. Those are mine.

Why Take This to Work?

The whole idea behind design patterns is to generate re-usable code that contains good OOP. I realize that a drag-a-face-part game isn’t going to impress your boss (if your boss is infantile, it might) but that’s not important. What is important is to emphasize the fact that as your applications become more complex, you’re either going to have to re-start building applications with every new contract, which will probably include several hacks, make-dos, and god-awfuls. When your customer wants change, it will take time and effort and blow the stuffings out of the current application. So maybe with a simple little face, you can dispel the idea that design patterns will add to a workload. They’re just there to help.

Also, I think that anyone over the age of 5 can do better graphics than I can. So, I’ve provided the entire application including both CS3 and CS4 versions for you to add your own beautiful graphics. (You wonderful graphics folks can send in a fixed-up FLAs with better graphics in the Library, and we’ll gladly add them on the front of this post!). Click the download button to get the whole enchilada:

This is my last post for 2009. See you all next year, and have a great holiday!

Take This One to Work

You will remember the initial query that launched this two-part post started with an inquiry into the possibility of dragging a Video while it was playing. In order to make the query more relevant to design patterns, this second part looks at the process for expanding the larger issue of dragging objects inside a Sprite. Whenever undertaking such a project, begin with the Variation Table (aka Magic Table) to find the possible variations. The wrong way to start developing a design pattern for a practical problem is to look at all of the different class diagrams and pick one that looks like it will fit your problem. Instead, always start by asking, what varies?

In this case, the “hitchhiker” to be dragged is the particular type of object in question. We saw how to drag a Video object, but what about other objects that need to hitchhike on a Sprite to be dragged? So, we’re talking about different objects—or put otherwise—object variation. The closest matching variation in the Magic Table is the variation of the subclass of the object that is instantiated. That means a Factory Method design. (See how easy that was?)

Next, I opened up the Design Pattern Catalog (which still needs to be finished) but includes all of the Creational Patterns. It provided the class diagram and other information about the Factory Method that I needed to get started on the project. Also, quite by chance the Design Pattern Catalog was developed using the Factory Method as well—in fact it uses two.

The Dragon Factory

One of the aids I’ve been using to develop design pattern projects is to create a class diagram made up of the files I’ll be using. This helps to give me an ongoing overview, and even though the files are devoid of content initially, they serve as a development map. Also, I like to start with the minimum number of elements needed. So I’ll need at least two different objects, or Product implementations. Since I’ve already got the Video, I’ll use it, and I’ll use the Shape object for the second hitchhiker object. Figure 1 shows the File Class Diagram for this project:

Figure 1: Dragon Factory File Class Diagram

In considering any Factory Method design pattern, GoF notes that you can select from two varieties. One variety is where the Creator is an abstract class and you subclass concrete creators as factory implementations . The other variety is to have a single concrete Creator class that serves as a big factory. (During the Soviet Era in the Russia, they had a huge truck factory the size of a small city that produced huge trucks in great quantities—sort of like the single concrete Creator class.) I opted for the abstract creator to keep the design looser. With a single Creator class I would have had to used conditional statements to farm out out the different types of objects, and as you will see I was able to keep the design if-free.

The Product Classes

The design called for two different objects, but I wanted to leave the door open for further objects that I could include in the design at a later date. Thus, the Product participant in the design pattern needed to be abstract, and so I used an abstract class. It set up one abstract method, a concrete property, and two concrete methods for dragging. The concrete property (named sled) is employed for giving the non-Sprite objects a ride. The abstract method provides flexibility in implementation for different objects. Given the difference between a Video object, including a Camera instance, and a Shape, the design needed that flexibility.

The following three listings show the abstract Product class (DragProduct) and the two implementations (DragVid and DragShape).

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
{
	//Abstract class--serves as interface
	import flash.display.Sprite;
	import flash.events.MouseEvent;
	import flash.errors.IllegalOperationError;
 
	public class DragProduct extends Sprite
	{
		protected var sled:Sprite=new Sprite();
 
		// ABSTRACT Method (must be overridden in a subclass)
		protected function setElements():void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		protected function doDrag(e:MouseEvent):void
		{
			this.startDrag();
		}
 
		protected function unDrag(e:MouseEvent):void
		{
			this.stopDrag();
		}
	}
}

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

package
{
	//Concrete Product
	import flash.display.Sprite;
	import flash.media.Camera;
	import flash.media.Video;
	import flash.events.MouseEvent;
 
	public class DragVid extends DragProduct
	{
		private const WIDE:uint=320;
		private const HIGH:uint=240;
		private var vid:Video = new Video(WIDE,HIGH);
		private var cam:Camera = Camera.getCamera();
 
		public function DragVid()
		{
			setElements();
			sled.addEventListener(MouseEvent.MOUSE_DOWN,doDrag);
			sled.addEventListener(MouseEvent.MOUSE_UP,unDrag);
		}
 
		override protected function setElements():void
		{
			cam.setMode(WIDE,HIGH,20);
			cam.setQuality(0,100);
			vid.smoothing=true;
			vid.attachCamera(cam);
			vid.x = 100,vid.y = 100;
			addChild(sled);
			sled.addChild(vid);
		}
	}
}

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

package
{
	//Concrete Product
	import flash.display.Sprite;
	import flash.display.Shape;
	import flash.events.MouseEvent;
 
	public class DragShape extends DragProduct
	{
		private var shape:Shape = new Shape();
 
		public function DragShape()
		{
			setElements();
			sled.addEventListener(MouseEvent.MOUSE_DOWN,doDrag);
			sled.addEventListener(MouseEvent.MOUSE_UP,unDrag);
		}
 
		override protected function setElements():void
		{
			shape.graphics.beginFill(0x009900);
			shape.graphics.drawEllipse(450, 10, 50, 50);
			addChild(sled);
			sled.addChild(shape);
		}
	}
}

In the two Product child classes (DragVid and DragShape) you can clearly see where the variation is in the subclass of object that is instantiated just like it shows in the Magic Table.

The Factory Classes

As noted above, I opted for the abstract Creator and relied on specific implementations for the factories that would individually create the different draggable objects. The abstract class that makes up the interface containes a single Sprite property and two methods; one public and concrete and the other, protected and abstract. The public method serves as a getter and the protected method returns the finished product. The following three listings show the Creator 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

package
{
	//Asbstract class--serves as interface
	//Creator
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class Creator
	{
		private var dragNow:Sprite;
 
		public function createDragable():Sprite
		{
			dragNow = getDragon();
			return dragNow;
		}
 
		// ABSTRACT Method (must be overridden in a subclass)
		protected function getDragon():Sprite
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
			return null;
		}
	}
}

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

package
{
	//Concrete Factory
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class VidCreator extends Creator
	{
		override public function createDragable():Sprite
		{
			return(new DragVid());
		}
	}
}

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

package
{
	//Concrete Factory
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class ShapeCreator extends Creator
	{
		override public function createDragable():Sprite
		{
			return(new DragShape());
		}
	}
}

The Creator implementations simply call for either a DragVid or DragShape instance. You may be thinking, you could have used a single Creator implementation (concrete factory) to call for one or the other with a simple conditional statement. However, I try to avoid conditional statements and keep the design loose. Why tighten up your design when you don’t have to? (You’re not going to run out of silicon. )

The Lazy Client

I’ve decided that I don’t want the client doing too much. After all, the Client’s job is to make requests; not to create things from scratch. It’s here to eat the cake; not to bake it. As a result, the client we have for this little project is pretty simple as you can see in the following listing:

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

package
{
	import flash.display.Sprite;
 
	public class Client extends Sprite
	{
		private var dragThing:Creator=new VidCreator();
		private var dragThing2:Creator=new ShapeCreator();
		private var rider:Sprite;
		private var rider2:Sprite;
 
		public function Client()
		{
			rider=dragThing.createDragable();
			addChild(rider);
 
			rider2=dragThing2.createDragable();
			addChild(rider2);
 
		}
	}
}

The Client implements each draggable object with just a few lines of code. It uses a Creator typed object to instantiate concrete factories. Then it uses the factories to call a method that cranks out the desired draggable products. Figure 2 shows what you can expect to see—as long as you have your camera hooked up.

Figure 2: Easily Amused Subject Contemplating Draggable Green Ball

If you’d like to give it a run, hook up your camera and click the “Play Button”:

Try dragging both objects—they drag just fine.

Why Take This to Work?

You might be thinking,

This doesn’t look useful…

It’s funny, the same thing was said about the electric motor and the Internet when they first came about. (It may have been packet switching, but you get the idea…) In their book, Head First Design Patterns, the Freemans have these little cut out pieces of paper you can use to help put different parts of design patterns and programs together. You’re supposed to move them around in different configurations to help you understand design patterns programming. You could do the same thing with a TextField probably. Oh, but I forgot! You can’t drag a TextField object. What was I thinking?

If you’re feeling lucky, then enter the contest. Who knows? You might just win, and then you can go nuts! We know, you’ll have to put up with the paparazzi and the inevitable groupies, but that’s just the cost of fame. (Our former winners will give you advice on how to handle it all.) Just remember Dirty Harry’s advice:

You gotta ask yourself one question: Do I feel lucky? Well, do ya, punk?

What is it?

In more than one post by design pattern enthusiasts, I’ve seen warnings against Design Pattern Fever with dire warnings about using design patterns for petty projects. Well, I don’t agree! From our survey, we found that while most would like to include good OOP and design patterns in their projects at work, most good programmers are under so much pressure to get the job done that they don’t have time for design patterns. So instead of kick-starting your design pattern work with a big project, start small with a Hello World! project.

The goal is to use a design pattern (any one you want except the Singleton) to output “Hello world!” in eight (8) different languages. In our last contest, we had winners from all over the world, and so having more than one language seems appropriate. (You get bonus points if one of the languages is Icelandic, Yoruba or Navaho.) The contest is from when you read this post until July 15, 2009. So get cracking and get lucky!

The Rules

1. You must use a Design Pattern from the original Gang of Four’s book
2. All entries must use ActionScript 3.0
3. Either Flash or Flex formats are acceptable
4. You may not use a Singleton design pattern (They’re pathological liars—that’s why.)
5. The screen output must show “Hello World” in eight (8) languages—either separately or all together. You cannot use trace() statements for the output, but all output must be visible on the screen.
6. You must specify which design pattern(s) you are using.
7. Extra points are given for Icelandic, Yoruba and Navaho
8. All entries must be in by July 15, 2009
9. All entries must be placed in a ZIP file. (Nothing fancy for my Mac)
10. Send entries to wdsanders@comcast.net with the subject line Golden Lunch Bucket Contest #2
11. Include your name, age, where you’re from, and a 100 x 100 jpeg/png photo

Remember, you can use any design pattern you want with the exception of the Singleton (shudder). This is a simple contest, and there’s no pressure—you’ve got until July 15! So grab that can of Red Bull and hop to it!

I recently returned from a trip to Prague in the Czech Republic, and I went to work creating a video player for my HD videos I made using a Flip Mino HD camcorder (http://www.sandlight.net/prague). Rather than pulling out and reusing my trusty State Design Pattern player (see Chapter 10), I decided to start from scratch and create a player not using a design pattern. Then I would take the completed video player and use it as an example to show how to refactor a program to a design pattern. (This will be in an upcoming post.) Since I’ve never had to refactor the original program (tweak, maybe but not refactor), and I hadn’t worked with a State pattern lately, I found myself digging up all of the materials on the State Design Pattern. What I wished I had was a handy desktop app that I could click that would show me the essentials of the different design patterns. It would be an abbreviated design pattern catalog that could be used like the little Design Pattern Principles and Lunch Bucket Rules AIR app. Then when I need a quick reference I could use the desktop app to look up the essentials of the pattern.

What Does a Design Pattern Catalog Need?

Right off the top of my head I came up with the following elements for a quick look-up:

• Class diagram
• Description of what elements vary
• Component roles
• Common usage
• Chapter/Blog reference
• Key Code examples

The catalog is meant to be a quick reference for someone who has some idea design patterns and wants to check out some elements of different patterns to see if it’s appropriate for a project. It is not meant to be a complete reference and certainly not a tutorial. Like the little AIR application that brings up the principles in abbreviated format, this application is meant to be a simple guide that will save time over pouring through Web searches or books and articles for basic design pattern information. Figure 1 shows an idea of what each page of the application would look like (given the above criteria). We’d like your comments on further ideas both in content and design. I’m not a designer.

Figure 1: Proposed Template for ActionScript 3.0 Design Pattern Catalog

Take a look at Figure 1 and see if you have any suggestions as to how we could make it more useful without going into a detailed explanation of the pattern. Would it be handy? Should anything be added or deleted? Is there a better design? Send in your comments.

The Magic Table in AIR

A while back we had a post on this blog that included what I called The Magic Table. It is a reference to the Gang of Four’s table where they list all of the design patterns and what can vary for the pattern. Anyway, I’ve always found that table useful, and so I created one using a simple DataGrid component. You can download it here. You can put the AIR app on your desktop and quickly find what can vary with each design pattern. Figure 2 shows what you’ll see.

Figure 2: Encapsulate what varies—Design Pattern Variation Table in AIR

If you can make something with better aesthesis, please do so, and we’ll be glad to make it available to our blog readers if it is sent in an AIR file. In the meantime, we’d like to get your comments on the utility of such tools and ideas to improve them.

Table 1 shows the results of the survey’s 163 records. These results are based on the following questions:

• Which API do you usually use for development? API
• At work, which of the following best describes the programming practices used? Practices
• In hiring developers, which of the following do you actually ask applicants about? Applicants

The queries about API and Practices are mutually exclusive and so their rows add up to 100% (mas o menos depending on rounding errors), but the third question is not mutually exclusive and each cell could be up to 100%.

Table 1: General Survey Results

Who’s Your API?

The API of choice is roughly equal between Flash and Flex with about 6% more using Flash than Flex. Another 21% indicate that they use both. We only had 2% whose shop used something other than Flash or Flex.

What Are Applicants Asked?

I found that the responses to the question about what applicants are asked when being considered for a job were quite revealing. The applicants were questioned about Flex and/or Flash roughly along the lines expected given the API choices. The great majority indicated that they questioned applicants about ActionScript 3.0 (85%), but I expected more like 100% would be. Likewise, most respondents said they asked applicants about OOP (77%). So whether you’re a Flash or Flex developer applying for a job, expect questions about OOP. Oddly, though, only 44% asked about the principles upon which OOP is based. (I’d be curious to find out exactly what kind of OOP questions were asked that did not include OOP principles.) Finally, 44% asked about design patterns, suggesting that a sizable proportion of software shops are interested in a programmer’s background in terms of some of the more advanced elements of ActionScript 3.0 programming.

Who’s Got the Practices?

From the raw data, I could not tell which group—Flex, Flash or Both—were the most likely to employ the best practices. In order to find out, I created a cross tabulation treating the API as the independent variable. I have to admit that the cross-tabulation I created using PHP did not adhere to the best practices—I’m just not that good of a PHP programmer to follow the practices that I do in ActionScript 3.0. (We’re all entitled to a hack every now and again.) Table 2 shows the results. (I dropped the cases that were neither Flash nor Flex.)

Table 2: General Survey Results
Examining the results of Table 2, about the only significant difference is that developers who reported using both Flash and Flex in their shops were far less likely to wholly disregard good OOP practices and design patterns and end up in the “Hack” category. Those who identified themselves as Flex or Flash developers, were about as likely to be in the Strict or Hack categories—15/15 percent for Flex and 13/15 percent for Flash.

About the only thing that can be said is that those developers who report using both Flex and Flash seem to use slightly better practices than those who only use one or the other. However, even when we consider the highest percent of those who are essentially using non-OOP/DP practices (Hack category), it’s very small—15% at most.

Where to Go From Here?

It is clear that the modal practices are ones where the developers recognize the importance of OOP and Design Patterns but have difficulty executing them. Overall, it seems that the ActionScript 3.0 developer community who completed the survey would like to employ good practices, which is a good thing.

We’d like to get your feedback on this topic and explore ways that good OOP practices and design pattern can be implemented quickly and easily implement at work.

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.

As a general way of making sense out of projects, they are divided into design and development. The design component usually means graphic design, but it can also include the UI (HCI) and information design—the kinds of things Edward Tufte talks about. In other words, design refers to everything that the user actually sees and interacts with. Those involved in design must expose their work to the user. It is in no way shrouded, and hence naked.

Developers’ work, on the other hand, has better cloaking than a Romulan space ship. If something goes wrong, and the program blows a gasket, the user can see a problem, but if things work, even in the most pedestrian program, the programming is invisible. The entire program can be one hack piled on top of another (as was the case with ActionScript prior to ActionScript 3.0), and no one would ever know. So, we programmers are safe to write any kind of code we want, and as long as it works, everyone is happy.

In many respects, most projects are design ones. The look, feel, navigation and interaction of a program makes or breaks it. A beautifully programmed project isn’t worth a bean if it looks poor, is difficult to navigate or interacts awkwardly with the user. Conversely, if a program looks and acts good, no one cares about what’s under the hood as long as it works.

An Exoskeleton for Programs

Suppose for a moment, that all programs had exoskeletons. The exoskeletons would be made up of the code used in the program. Everyone would be able to see your code and the kind of programmer you really are. Not only would they be able to see the kinds of work that designers do, they could simultaneously see under the hood. Ask yourself this: Would you clean up your code if everyone could see it? I know that I would and do. If you write about programming whether its in a book, an article, or a blog, you think about those things a lot, and your code certainly is visible. All of your examples are open to scrutiny.

Oddly, the worse reason that I can imagine to improve my own coding habits is to impress others. At some level, motivation matters. If I am not clear on why programming practices embedded in design patterns and OOP are important and matter for creating better programs, then I doubt I could sustain an interest in design patterns. For me, the practices are important for what they do—namely create reusable code subject to change and renewal.

Confessions of an Algorithm Dope

I doubt there’s anyone who reads this blog who doesn’t want to be a better programmer. (That includes Chandima and me—we’ve read all the comments in addition to the posts we’ve created looking for clues to better programming.) In working with design patterns we’re confronted with the issue of what it means to be a good programmer and write a good program. The other day in thinking about what good programming means I remembered when I was getting started writing code , all I wanted to do was to create better algorithms—

I was an algorithm dope.

At the time I was fascinated by sort algorithms and spent endless hours trying to understand all of the different sort algorithms. To me, a better algorithm meant better programming. I still believe that, but I’ve also come to realize that’s only part of what it means to be a better programmer. However, being an algorithm dope for many years, it blinded me to the larger picture in programs.

A Good Pilot and a Good Programmer

Some years ago when I lived in San Diego I owned an airplane. Looking for things to do with my airplane, I joined a couple of groups, The Flying Samaritans and Liga: The Flying Doctors. We flew medical supplies, doctors, nurses, interpreters, and other medical folks down to clinics in remote areas of Mexico. All of us had instrument ratings and many were commercial pilots. The talent pool of those groups was wide and deep. Navigation was often a challenge, and the landing strips were dirt or sandy soil. We had to check for people, cows and other surprises on these strips prior to touchdown and land a full planeload of people and supplies. For pilots, these flights were a challenge to skills honed by practice and study—really what flying was all about. That’s why pilots who flew commercial jetliners would often fly with us. We got to do the fun stuff.

At one point I was assigned the job of Safety Officer. I was responsible for making sure that the pilots were current and followed the flying rules we had established plus those of the FAA. Also, if any mishap occurred, my job included finding out what happened and integrate new guidelines to avoid a repeat occurrence. On one flight, one of our planes crashed with severe injuries but thankfully no deaths. (A television movie was actually made of the incident!)

When we had a hearing to determine the events that led up to the crash, we learned that the pilot was attempting to fly under a bridge. At the last moment, he changed his mind. When he pulled up to fly over the bridge, he ran into a metal cable that brought down the aircraft. For his defense, another pilot testified that he was a very good pilot and had landed safely at small remote strips without incident many times. Naturally, we asked what was he thinking by flying so low as to endanger himself and his passengers. He angrily demanded,

Are you saying I’m not a good pilot!

What he meant was, “Are you saying that I can’t fly an airplane?” He wanted to know if we were implying that he lacked the skills to make the airplane do what he wanted. We were saying something very different—namely that he lacked good judgment. It wasn’t that he couldn’t fly an airplane, but rather he put himself, his aircraft and his passengers into dangerous situations.

Recalling the landing of Flight 1549 on the Hudson River by Captain Sullenberger, most people saw the ability to land a powerless aircraft on water without serious injury as a marvel in flying ability. Successfully ditching an aircraft on water is no mean feat, but what was more important than the ability to safely make a water landing was the decision to do so. When the power was lost, “Sully” had several options. He was cleared to return to LaGuardia Airport or go to nearby Teterboro Airport, and initially he announced that he was returning to LaGuardia. Landing at an airport is a far more attractive option and in some situations, the safest. The pilot quickly realized, however, that an airport landing was not viable, and so he decided that the best option was to bring the aircraft down on the Hudson River. To me (and I imagine to most pilots), that kind of judgment was the most important feature that Sullenberger possessed as a good pilot.

On top of that, Sully and his co-pilot had a plan. The plan was in the form of a pre-prepared checklist for ditching that particular make of aircraft on water. One of the steps in the checklist was to press the “ditch button.” The button triggered events that closed the outflow valve along with several other open values. By closing the valves, the plane was able to stay afloat longer. Had they not had a checklist to guide them through the steps, they may well have overlooked pressing the ditch button, and the results may not have been as successful as they actually were.

Good Programmers and Stupid Dog Tricks

When I program, I actually believe that there’s nothing I can’t make ActionScript 3.0 do—within the limitations of the computer, Flex Builder or Flash. When I want to test a concept I’ll whip together something that I think of as a stupid dog trick. It gets the result I want. Sometimes I’ll have to work at it for hours or even days or weeks, but by hook or by crook I can get it done. Once I get the stupid dog trick code finished, I’ll start thinking about doing it right if it’s something beyond a test of concept. However, what a good programmer does is to plan first and then write the code. In David M. Bourg’s book, Physics for Game Developers (O’Reilly, 2002), he discusses making a flight simulator. However, prior to writing the code, he suggests beginning with a flight model that lays out what physics are involved in making an airplane fly. The most basic physics for an aircraft are lift, thrust, gravity and drag; so in the modeling process you want to plan for those forces. This comes way before you start thinking about how you’re going to simulate this in 3-D or how you’ll set up the user interface so that the gamer can make the aircraft perform a split-S. You have a basic outline of what you’re going to do before you start writing your code that makes the application.

With all serious projects in programming, I have forced myself to plan first and then start the coding.

One thing that I discovered is that planning can be fun.

When I used to fly, I’d spend hours planning a flight. I’d check the weather along the route, the navigation aids (e.g., VOR’s, radio stations) and make notes about the topography (e.g., mountains, rivers, visible landmarks). Now in flying, this can be a life or death decision. On one flight my wings iced up, and with no de-icer I began losing altitude over a mountain range. From planning, I knew at what altitude the ice would melt, and it was well above the mountaintops. The ATC was a little panicked and instructed me to maintain an assigned altitude, but because I was unable, I told him I would do so as soon as I could. I wasn’t about to attempt something that the aircraft was incapable of doing and possibly stall. No icing had been reported by ATC or in the weather forecast, but having flown the route often, I knew that it was a possibility. I was quite satisfied with myself for good planning. I know that sounds smug, but like good programming that’s been carefully planned and crafted, when everything comes together, there’s a feeling of doing something right. Maybe it is a bit smug, but so what?

A Program Plan is a Principle Plan

Not long ago I had to refactor a disaster done with ActionScript 2.0. The program looked good when executed, but it was one stupid dog trick piled on another. (A stupid dog trick pile!) I pulled all of the code out of the Actions panel, and began work on getting it right. Because I wanted to maintain the UI and graphic design, I had some constraints, but I knew it could be done. So the first thing I did was to create an abstract class to handle navigation. The navigation bar had been split in two, each with a set of buttons displaying an image of a video that would play by pressing the button. Having an abstract class for navigation, I was able to create two concrete classes, one for each segment of the navigation bar. Not only did the navigation buttons trigger a video, they also triggered two text files—one for a header and one for the body text that accompanied the video. So naturally I wanted a class for the text and so created an abstract class to handle text and then implemented concrete classes for the body text and header text.

The focal principles were, (1) program to an interface, not an implementation; and (2) encapsulate what varies. By setting up abstract classes, I was able to make my references to the interface (typing the instances to the interfaces). Anyway, I finished it up, and while my plan was rudimentary—it was jotted down on the back of a discarded daily calendar page,— it was a plan. The other day I ran into a friend who had seen the page where we had the application, and she wanted one like it for her videos. We sat down, and after showing her what to change, she was able to adopt it for her own application.

I did not use a design pattern. Had I used a design pattern, building it would have been easier, but because I followed the principles used in building design patterns, it worked very well. Most importantly, it was easily re-usable on a different application.

Good Programmer’s Checklist

In flying, we used a checklist to make sure that we didn’t forget anything. Usually, the walk-around with the checklist was uneventful, but every now and then, I’d find a problem. One day I found water in the gas tank, and drained out the water as required. Had I not used the checklist, I may have found an unpleasant surprise while a couple of miles up in the sky. Recently, I learned that hospitals are beginning to use similar checklists to make sure that all of the steps in medical procedures are met. The reason for checklists in hospitals is that they have been sued for medical mishaps. (One poor guy had the wrong leg amputated!)

As an algorithm dope, I never needed a checklist. However, as I began paying attention to OOP principles, I decided it was a good idea to have one. The one I made is a bit silly (Programming Checklist) but as an AIR application I can keep it handy on my desktop and it’s easy to use. More recently, I indexed all of the principles discussed so that I could find needed details about the principles easily.

So unlike Flash designers, we developers work in the dark and our projects have no exoskeleton. As long as our code works and the user doesn’t have to wait too long for the program to load, everything is Jake. What’s more, we can create junk code that works, and instead of elegantly adjusting a class or method to make changes, we can cut and paste more junk code and get things to work. If we don’t know any better that’s one thing. However, if we know about good programming practices and don’t use them, eventually our programming souls wither and die. So I’m going to add one more item to the checklist—

Save your programmer’s soul!

Remember, unlike the naked designer, only we know when we’re doing it right.

We got to the point where the posts on the Principles of OOP and Design Patterns and the discussions of introducing Design Patterns to the workplace became so numerous that they were difficult to locate on the blog. This is the first index that we have, and as we continue to grow, we’ll have to add more. (We are certainly nearing that point with MVC and Pure MVC posts.) So, in the “Categories” section of our blog, we’ll be adding indices as needed. Look for the Index category to locate all indices.

Principles:

OOP and Design Patterns Ready for Work
• This post includes a quick guide to all of the principles discussed in the form of an AIR application that you can store on your desktop for a quick reference.

Link

Magic Table: What Varies in a Design Pattern

• Download Magic Table AIR Application

The Liskov Substitution Principle
Link

Program to an Interface; not an implementation
Link

Favor Object Composition over Inheritance
Link

Separate what varies from what stays the same and encapsulate what varies
Link

Objects should be loosely coupled
Link

Classes should be open for extension but closed for modification
Link

High-level and low-level modules should depend on abstractions (Dependency Inversion Principle)
Link

Only communicate with closely related object (Least Knowledge Principle)
Link

High-level components can call low-level components, but low level components never call high level components (Hollywood Principle)
Link

Your class should have one and only one responsibility (Single Responsibility Principle)
Link

Is Your ActionScript 3.0 Design Good? : The Three Keys of Good Design
Link

No New is Good New: Using Inheritance, Composition, Delegation and anything else other than New in ActionScript 3.0 Design Patterns
Link

Design Patterns at Work

Why Design Patterns?
Link

Strategy Design Pattern for Work
Link

Decorator Design Pattern for Work
Link

Not at the Children’s Table Anymore
Link

ActionScript 3.0 Developers: The Children’s Table Revisited
Link

No Time for OOP and Design Patterns
Link

Take a Design Pattern to Work Part I: Identifying the Problem
Link

Take a Design Pattern to Work Part II: A Little OOP
Link

Take a Design Pattern to Work Part III: Loosening Up
Link

Take a Design Pattern to Work Part IV: Establishing a Design Pattern Foundation
Link