It's my first time too!

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

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

The parent class tells the child class the same thing.

Class Diagram

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

Figure 1: Template Method Class Diagram

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

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

Abstract Classes and Primitives

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

1
2
3
4
5

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

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

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

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

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

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

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

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

Page Arranger

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

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

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

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

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

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

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

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

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

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

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

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

I’ve got nothing against 4th Graders.

It was in relation to the MVC, which is the precursor to the Gang of Four’s catalog of patterns, but it’s appropriate in this discussion as well. Originally, I was asked what I had against MVC, and I said, Nothing, and I’ve got nothing against 4th graders either. The reference was to getting stuck in the MVC in a continuous loop—just like getting stuck in the 4th grade. The MVC is brilliant because it helped free programmers from monolithic conceptualizations in programming. However, it’s a starting point; not an ending point. The Pure MVC advocates certainly agree with that idea, and that’s fine, but pure or (impure?) MVC, it’s still an MVC. The GoF make the point that different patterns can be developed around what varies in an application, and the MVC is a way to deal with UIs and has much in common with the Observer pattern; which leaves some 20 other patterns that focus on different variations. (Later developments of the MVC have elevated it to an architecture.)

In my own case, I got stuck on the State pattern for about a year and decided that it was time to move on after realizing that other patterns would serve me better when something other than state varies. Redoing my Web site now, I wish I had used design patterns in more than the video player I made with a State pattern.

Why OOP? What’s Wrong with Sequential Programming?

First off, let’s get straight what we mean by sequential programming. In one context, it means Not Parallel Programming or Not Concurrent Programming. Just ask anyone at Intel. They think that everyone should learn concurrent programming based on the fact that their processors are all multi-core, and single core processors have gone the way of the Dodo bird. They’ve got a point. In looking at my collection of computers my old Win XT may be single core, but I’m not even sure that’s it’s not a dual core. My Macs and Win 7 (64-bit) systems are all dual or quad core. (See Joe Duffy’s book, Concurrent Programming on Windows for about 1,000 pages of info on this kind of programming.) Just to be straight about the point, that’s not the kind of sequential programming I’m talking about.

In this post, I’m referring to non-structured programming where you just write one line after another. When I used to write assembly language programs (especially using the assembler I wrote myself) everything was non-structured. Likewise, a lot of the Basic programming I wrote was sequential along with Fortran and non-Pascal stuff. If I had to put a date on it, I’d guess such programming is about 60-70 years old. It’s not old school; it’s just old.

What’s wrong with sequential programming? Is it slower? Does it not execute correctly? Are there algorithms I cannot write with it?

No to all of the above.

It’s main shortcomings center around the spaghetti factor. After not too many lines of code, it’s easy to get tangled up. If your programs are short, you’ve got little to worry about with good ole’ sequential programming. Otherwise, sequential programming is difficult (near impossible) to maintain, change and keep straight.

However, you’d be amazed by the number of programming books that still present coding in nothing but sequential structure—which is non-structured. (In the past I’ve been guilty of the same thing; so I’ll be throwing no stones.) Some authors who have attempted to do otherwise have been snarled at…What about the beginners? What about the non-developers?! Grrrr! So it’s not just complacent code-writers who create programs in nothing but sequential structures; some authors do the same.

To be fair, a lot of the code in computer books is presented in snippets—little bits of sequential code to explain the syntax or to provide a working example. That’s fine and not what I’m talking about. In good books all of the bigger examples are in OOP or at least procedural programming. What I’m talking about are books where everything in the book is presented as sequential programming. One I have in mind showed a three-tiered if statement that was part of a bigger sequential monstrosity. How that mess helps beginners is beyond me. (By the way, the particular book I have in mind was published in 2009 by one of the most reputable computer book publishers in one of the most respected series.)

Oddly I found that by working with design patterns I end up doing simple sequential snippets—none of the messy spaghetti stuff. Read on to see why.

Procedural Programming to the Rescue!

If I had to summarize procedural programming in one word, it would be functions. If I see the keyword “function” in a program, I can assume that the programmer is at least using procedural programming. The great thing about procedural programming is that you can re-use the same function all you want and it’s a whole lot easier to organize a task.

The problem that comes up in procedural programming centers around scope. Global variables can be used with many different procedures (functions), but they are more likely to creep in where they’re unwanted and screw up a program. Local variables are tethered to functions, and you may have occasion to use one of their values, but since they’re scoped to the function, they have a whole other set of issues. So while a huge improvement over sequential programming, programmers still had many challenges to face with procedural programming.

OOP Emerges: Encapsulation

Like Procedural Programming that can be summarized by the use of functions, Object Oriented Programming (OOP) can be summarized by encapsulation. To prevent the scoping problems and aid in debugging, the concept of the object emerged as a fully contained set of properties (something like variables) and methods (encapsulated functions). The objects were built in classes and a set of rules regulated communication between objects using accessors—private, protected and public. Classes represent abstractions of different entities that can be used to get something done in a program. The key to getting something done is through communication between the objects and implementing concrete instances of abstract classes. That’s an oversimplification, but clearly the focus shifts from sequences to communication.

Design Patterns: Organized but Loose

While OOP went a long way to create a programming model that could handle larger programs, some of the communication between objects resulted in a kind of binding that made re-use and change very difficult. In fact, some large and complex programs requiring even a little change had to be re-built from the ground up.

In 1979 the Model View Controller (MVC) offered a way to build interfaces for SmallTalk using the MVC triad of classes. It was key in de-coupling classes that had previously been grouped together.

In 1995, Gamma, Helm, Johnson and Vlissides came out with a catalog of 23 design patterns organized around the purpose of the pattern (Creational, Structural and Behavioral) and the pattern scope (Class or Object). They offered six different criterion for selecting a pattern, key among them examining what you want to vary to avoid redesign and encapsulate what varies.

Professional programmers, in both industrial and higher educational settings, adopted or professed the use of design patterns. The purpose then as now is to aid in the development of software that is characterized by change and revision. In some respects they are OOP solutions to common programming structures. They are not templates as design templates in graphic design are. Rather they are broad yet precise ways to organize classes around frameworks with a general and common programming goal.

Do Design Patterns Add to or Reduce Complexity?

For some, all that design patterns accomplish is to create a more complex system for both thinking about programming and creating a program. True, they do take some time to fully grasp, but so does programming. However, design patterns provide a fairly complete set of structures for dealing with programming problems. Further, once adopted, they save a great deal of time in re-structuring and making program changes.

Oddly, using design patterns, I find myself back writing simple sequential code. Consider the fact that classes should only take on a single responsibility and are organized around an abstract interface. I know the required signatures for the method, and I know the classes and their relationship to other classes. So what’s left for me to do? I just write snippets for the methods—little sequences of code that are fired when the method is called. Because objects are organized around a known communication system (a framework), I don’t have to worry about how they get along with the other objects. All of my requests are from a Client class, and the requests are nothing more than little sequences that instantiate a class and use the object’s methods and properties.

Now, I go back and look at the “easy” and “fun” book that has nothing but sequential programming (the word “function” is not even in the Index). I see a river of nested conditional statements in loops. That’s easy? Revision? Forget about it! I’m happy writing my little snippets inside well organized methods inside classes that I can easily re-use and revise.

Moving from Inheritance to Composition

While waiting around for someone to offer up a dynamic client for the Abstract Factory, I started thinking about the whole concept of single responsibility. This is nothing new, and we have a post on the topic, but it’s one of those things that keeps nagging at me, and I thought it’d be a good topic of discussion. What keeps buzzing around my mind is the concept of single. In team sports, different positions are assigned different responsibilities. One of the most unique positions is that of the goalkeeper (or goalie) who is the only member of the team who can use his hands. So I thought that it’d be a good idea to begin with the goalkeeper.

The Duties of a Goalkeeper

Classes should have only a single responsibility

Going with Granular

After pondering this for a bit, I decided to set up a drawing interface and treat each drawing as a different object—rectangles, ellipses and triangles. A single interface provides a degree of looseness and cohesion at the same time. All calls from the Client can be made to the interface and the same method is used for each object. Figure 1 shows the class diagram for this segment.

Figure 1: Drawing interface and concrete implementations

The interface needs enough parameters so that all of the implementations have enough parameters for each argument that Client needs to create the desired shape. All of them need a color parameter for the fill operation, and both the ellipse and rectangle need four other parameters. However, the triangle requires six parameters; so the interface will have to have a total of seven parameters—one for the color, and then six more for drawing. The following listing shows the interface:

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

package
{
	import flash.display.Shape;
 
	public interface IDrawMaster
	{
		function drawNow(fill:uint,
					p1:Number,p2:Number,
					p3:Number,p4:Number,
					p5:Number,p6:Number):Shape;
	}
}

Other than using a descriptive parameter name for the color parameters, the others are named p1-p6. Also, rather than returning a Sprite, this returns a Shape object.

The implementations for each of the shapes is fairly simple and involves a bit of cut and paste—more to avoid typos than to save time. The following three classes are implementations of the interface:

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

//Rectangle
package
{
	import flash.display.Shape;
 
	public class BoxMaker implements IDrawMaster
	{
		private var archGraphic:Shape=new Shape();
 
		public function drawNow(fill:uint,
						p1:Number,p2:Number,
						p3:Number,p4:Number,
						p5:Number,p6:Number):Shape
		{
            archGraphic.graphics.beginFill(fill);
            archGraphic.graphics.lineStyle(2,0x82877A);
            archGraphic.graphics.drawRect(p1, p2, p3, p4);
            archGraphic.graphics.endFill();
 
            return archGraphic;
		}
	}
}
 
//Ellipse
package
{
	import flash.display.Shape;
 
	public class EllipseMaker implements IDrawMaster
	{
		private var archGraphic:Shape=new Shape();
 
		public function drawNow(fill:uint,
						p1:Number,p2:Number,
						p3:Number,p4:Number,
						p5:Number,p6:Number):Shape
		{
			archGraphic.graphics.beginFill(fill);
			archGraphic.graphics.lineStyle(2,0x7C389E);
			archGraphic.graphics.drawEllipse(p1, p2, p3, p4);
			archGraphic.graphics.endFill();
 
			return archGraphic;
		}
	}
}
 
//Triangle
package
{
	import flash.display.Shape;
 
	public class TriangleMaker implements IDrawMaster
	{
		private var archGraphic:Shape=new Shape();
 
		public function drawNow(fill:uint,
						p1:Number,p2:Number,
						p3:Number,p4:Number,
						p5:Number,p6:Number):Shape
		{
			archGraphic.graphics.beginFill(fill);
			archGraphic.graphics.drawTriangles(Vector.<number>([ p1,p2,  p3,p4,  p5,p6]));
			archGraphic.graphics.endFill();
 
			return archGraphic;
		}
	}
}

Now, we have a nice loose set of drawing objects and a single interface we can use to whistle up what shape we want.

The Composer Client

The final step in this installation is to create a client that uses the different objects. In effect, the actual composition is done in the Client. Ultimately, that’s not what we want, but for now, you can clearly see how composition is done.

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

package
{
	//Colors: B2D1C2,389E6B,356B31,765478,7C389E
	import flash.display.Sprite;
 
	public class Client extends Sprite
	{
		private var drawToolBox:IDrawMaster=new BoxMaker();
		private var drawToolEllipse:IDrawMaster=new EllipseMaker();
		private var drawToolTriangle:IDrawMaster=new TriangleMaker();
		private var dummy:uint=0;
 
		public function Client()
		{
			addChild(drawToolBox.drawNow(0xB2D1C2,50,50,400,300,dummy,dummy));
			addChild(drawToolEllipse.drawNow(0x356B31,300,100,100,60,dummy,dummy));
			addChild(drawToolTriangle.drawNow(0x765478,100,100,220,80,200,300));
		}
	}
}

So now, when we look at the Client, it creates three objects, all typed as the IDrawMaster interface. Then each object’s drawNow() method is called to draw some kind of object. (By the way, the drawNow() method is a perfect example of polymorphism.) With both the ellipse and rectangle classes, I added a dummy variable so that it wouldn’t throw a ‘wrong number of arguments’ error. It reduces confusion (I hope.)

At this stage, the coupling between the Client and the object it composes is still tighter than we want. So in the next installment, we’ll see about adding a factory to loosen things up. However, you still have a great opportunity to create a Client with an interactive interface in either Flash or Flex. What are you waiting for?! Hope to hear from you.

Agile, Design Patterns and Unit Testing

If the senior programmers at Google (and I would imagine Adobe, Apple, Microsoft and elsewhere) have a mantra in programming, it’s probably something like this:

Keep it agile!

As most of you know (or suspect), Design Patterns are a type of Agile programming, and the development of both (DPs and Agile) in the 1990′s overlap in content and developers. They were all reading each other’s articles and contributing to one another through venues like OOPSLA and ACM (Association of Computing Machines). The agility movement was in part a reaction to heavy-handed, micro-managed systems of software development processes that were par for the course up to that time. This was not a rebellious overthrow so much as a realization that in order to get things done the processes had to change. In other words, Agile programming and Design Patterns were children of necessity as much as innovation.

The Agile Manifesto

In 2001, a number of developers put forth what they called the Agile Manifesto. It is a concise list of what they have come to value—here it is:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The forgers of the Manefesto go on to state that while there is value in the items on the right (normal), we value the items on the left (bold) more.

For those of you expecting something dramatic or revolutionary, you might be disappointed by this tepid manifesto. (These guys aren’t Marx & Engels even though they have PhotoShopped a picture to look like an impressionist painting of anarchists gathered in an ill-lighted London basement as they plan to overthrow the hoary capitalists). Nevertheless, you can see how such a value system is tied into a movement to get out from under the sludge dictated by a focus on protocols rather than results.

No Real Work

As part of unit testing, Miško Hevery argues that the constructor functions should do no real work. By real work, Hevery means,

When your constructor has to instantiate and initialize its collaborators, the result tends to be an inflexible and prematurely coupled design.

For developing design patterns, you can see where this idea is crucial. If each participant (participating class) in a design pattern instantiates/initializes the other participants, you’d get instant lock-jaw. The flexibility and reusability that design patterns afford are lost.

So what should Constructor Functions look like? How on earth can we create agile or any other kind of software if we cannot use collaborating classes through instantiation? The answer to these questions can be seen in good design patterns. The patterns themselves are set up so that you do not make the mistake of having constructor functions, outside of the Client, doing real work. In Part II of this post, we’ll look at some examples. Until then, take a look at some Agile programming to loosen up.

S: Single responsibility principle
O: Open closed principle
L: Liskov substitution principle
I: Interface segregation principle
D: Dependency inversion principle

My favorite is the giant Swiss Army Knife in the Single responsibility principle:

Now, whenever I start loading up a class with more functions than the giant Swiss Army Knife, I’m reminded to throttle back! You’ll have a lot of fun at LosTechies.com with other articles on design patterns and OOP. They’re not ActionScript, but they’re informative.

Here are some other speakers you might want to hear/meet:
1. Miško Hevery
Automatic Dependency Injection In The Land Of Dynamic Languages

2. Barbara Liskov (Liskov Principle)
Keynote Speaker

3. Ralph Johnson (GoF)
Regrowing a Language: Refactoring Tools Allow Programming Languages to Evolve

Anyway, just in case any of you will be there, drop by one of the sessions. Everyone’s been very accepting of ActionScript 3.0, and it’d be fun to chat with some fellow ActionScripters!

“Do Not Use Design Patterns Upfront” http://tr.im/uI3a – I don’t agree. Beck & Gamma did just that with JUnit http://tr.im/uI3z #asdp
1:09 AM Jul 30th by @chandimac

@chandimac no we didn’t. we explained junit with patterns, but we started with one tiny test and grew the whole thing from there.
6:33 AM Jul 30th by @kentbeck in reply to @chandimac

@kentbeck TX for the clarification. Do you recommend “thinking in patterns” early or should they be added at a later refactoring stage?
6:30 AM Jul 31st by @chandimac in reply to @kentbeck

@chandimac i prefer to put patterns in place just before they become useful. if i can’t see how to do that, then soon after.
6:51 AM Jul 31st by @kentbeck in reply to @chandimac

JUnit A Cook’s Tour explains the design of a system by starting with nothing and applying patterns, one after another, until you have the architecture of the system. As Kent pointed out, the article was written that way, and I had incorrectly assumed that JUnit was developed that way as well.

Design Pattern wisdom in 140 characters

I put patterns in place just before they become useful. If I can’t see how to do that, then soon after.

– Kent Beck

I was quite intrigued by Kent’s reply to my follow up question. It got me thinking about a bunch of issues. What does it mean for a design pattern to be “useful?” How much before is “just before?” What does it mean to “put patterns in place?”

I was so intrigued that I re-read a bunch of stuff on refactoring and design patterns by Beck, Gamma, Kerievsky and Alexander. I try my best to answer some of the questions raised in the remainder of this post – or more appropriately, reconcile some of my cognitive dissonance.

In which ways are design patterns “useful?”

One of the oft suggested reasons for using design patterns is that they “make object-oriented design more flexible, elegant, and ultimately reusable.” That is a direct quote from the GoF Design Patterns book. Although elegance will bring immediate gratification, the fruits of flexibility and re-use are realized in the future, most often during subsequent refactoring. So, in the context of Kent Beck’s preference to apply patterns just before they become useful; is the only useful reward for thinking in patterns upfront, the personal satisfaction of doing something elegantly?

I think we get a little hung up on the flexibility and re-usability that design patterns bring to software development and forget about another aspect that is equally important.

I  found it helpful to go back to Christopher Alexander’s  books on architectural patterns and his argument for design patterns in architecture. Good architecture communicates both form and function. Alexander concentrated on deriving the basic functional attributes of different architectural elements. For example, in A Pattern Language, he said the following about the main entrance.

Place the main entrance of the building at a point where it can be seen immediately from the main avenues of approach and give it a bold, visible shape which stands out in front of the building.

The main entrance can take many forms but its function is common across all main entrances. It has to unambiguously communicate to a person that it is the main entrance. The position of the entrance relative to avenues of approach and its shape compared to other entrances communicates this function. How did Alexander come to this conclusion? By studying main entrances in different buildings designed by different architects and deriving their most salient characteristics.

The architectural pattern for the main entrance does not say anything about how the entrance should be built, what materials to use, dimensions and similar minutia. All it does is communicate its functional attributes at a high level.

Software design patterns communicate intent and function at a high level of abstraction as well. This happens at a much higher conceptual level than lines of code, methods, and individual classes. Patterns communicate in the voice of the collective intelligence of thousands of expert developers who tried, tested, modified and otherwise fine-tuned code in response to a common programming problem until a generic pattern could be identified in the solution.

Just like architectural patterns, software design patterns communicate meaning. They not only tell you that there are relationships between classes, but provides reasons for why those relationships exist. Erich Gamma described this very well in How to Use Design Patterns in Leading-Edge Java Magazine. Although JUnit was developed in a test-driven way, Kent and Erich had highly abstract conversations about the design of JUnit using design patterns. Design patterns provided a “design vocabulary” to expedite development -  Gamma calls this “high-velocity design.”

So, design patterns provide developers with a “design vocabulary” to discuss application design. But what about the individual developer? Is the meaning conveyed by a “design vocabulary” as useful to an individual developer even if he/she doesn’t need to communicate it to someone else?

Is a design vocabulary useful to you?

Design patterns provide a set of concepts describing how and why a set of classes relate to each other, and the order in which they interact with each other. Forget about flexibility, reusability and elegance for a minute; Is the advantage of being able to visualize code at a higher conceptual level reason enough to think in terms of design patterns upfront? Do a simple test, think of a design pattern that you know and understand well. What comes to mind? Do you see code or something else?

ActionScript 3 developers use design patterns every time we sit down to code. How? because AS3 is rife with native implementations of design patterns. For example, the Flash display list implements a Composite Pattern.  Another example is the AS3 Event model, which follows the Chain of Responsibility Pattern by bubbling events up the display hierarchy.

When I think about nested movie clips, I see hierarchical trees with events shooting up and down the hierarchy like lightning bolts. I find this type of visualization incredibly useful to internalize the relationships between objects. Design patterns provide the scaffolding for me to visualize these relationships.

Jesse Freeman wrote a good article recently called 3 Design Patterns Built Into AS3. Can you spot others?

How much before is “just before?”

This is an interesting question as well. If we take the literal meaning of “just before” we will miss the point. We must take “just before” in the full context of Kent’s statement. He says “just before they become useful.” So, the larger question is when do patterns become useful?

Design patterns allow code to be “flexible” allowing  developers to handle change elegantly. Flexible programs are no doubt useful, but are the fruits of flexibility immediately useful? We tend to think  that “change” in code as something that happens way down the road, such as the release of a new version of an application. But does “change” happen on a day-to-day basis? When you consider that most programming projects are not coded in a day, we realize that programming is a continuous exercise in “change.” You may write some code today, but tomorrow you might think that it really “stinks” and modify it or scrap it altogether and start afresh.

This is very well described by Kent Beck himself in a callout in the excellent book, Refactoring: Improving the Design of Existing Code.

Programs have two kinds of value: what they can do for you today and what they can do for you tomorrow….If you can get today’s work done today, but you do it in such a way that you can’t possibly get tomorrow’s work done tomorrow, then you lose.

For example, you may have an inkling that the algorithm you are using today may not be optimal, and decide to integrate a strategy pattern so that it gives you the flexibility to integrate a different algorithm tomorrow without disrupting existing code.

I do realize that Kent’s quote was made in the context of refactoring code. Refactoring to design patterns is also refactoring. So, is putting a pattern in place today to  ease tomorrows work considered “just before it becomes useful?” What do you think?

What does it mean to “put patterns in place?”

The original question that prompted me to write this article was whether design patterns should be put in place only in a refactoring context or whether it is useful to think in terms of design patterns upfront as well. One argument can be that it depends on the development methodology.

For example, if you follow an agile development approach, design emerges from iterative refactoring. In most cases, development relies on feedback provided by tests to drive the design. In this scenario there is not much option but to put design patterns in place during refactoring.

On the other hand, if you follow a more prescriptive approach ( for want of a better term ), there is an emphasis on planning and modeling before coding. In this scenario, there is an opportunity to put patterns in place up front.

One could also argue that it really doesn’t matter because in most projects we use a combination of both development methods.

Ultimately my driving question will probably transform into an argument between the merits of different development methodologies. There is no doubt as to the “usefulness” of design patterns and it may not matter whether you put them into place up front or during refactoring – either way, you will get the benefits.

The other day I was thinking about programs with tight code and loose coupling. Having been raised on tight coding I started looking around for a decent definition of tight code and came across one of my programming heroes, Charles H. Moore, inventor of FORTH programming language. For Moore, as well as others discussing tight code, the term refers to

… a program that is written very efficiently.

That doesn’t say a whole lot, but it says everything. In FORTH, not a single electron is wasted in the code, but not a lot of people use it because you have to think like a processing stack—last in first off. In other words, you have to think exactly backwards from normal sequencing. Ergo, most programmers have migrated to a high level languages with a C++ type of format such as ECMAScript and ActionScript 3.0. To some extent, efficient code is code without superfluous elements that gets a job done. (That’s why I don’t like to use conditional statements where I can help it—there’s generally a more direct option.)

In the context of OOP, I think that tight code can be equated with tightly woven objects. Such objects are good at what they do and nothing else. We can apply the single responsibility rule:

A class should only have a single responsibility.

However, they can work with other objects.

Where we run into trouble with tightness in programming is with Tight Programmers. Their structures are so tight that their objects cannot interact with other objects. Updates? Forget about it! They don’t want updates. In fact if a customer wants an update she’ll be told that she should have thought about that before he wrote all of the code. Is the code tight? Sure, it’s tight. Unfortunately, it is also inflexible. We need to differentiate between tight coding and inflexible coding. Tight coding is lean and purposeful. Inflexible coding resists change and updates. Design Patterns embrace loose coupling and tight coding.

Loose Coupling and Loose Practices

When we used to throw a program together, we called it strong-arming. We basically threw code at a problem until it did what we wanted. Good practices? What practices? We just beat the crap out of it until something happened. That kind of programming is what some consider (politely) as loose coding. In some respects, it’s like programming by committee—anything that works is included in the program. However, the committee is a committee of one—the programmer.

You want change? Hand me that baseball bat and let me fix it right up!

Oddly, loose coupling in programming requires more structure than tight coupling. With tight coupling, you can wrap up a program in a single class that has more lines of code than the national debt. With loose coupling you need to have a well-planned structure so that you can easily know what classes to add and what kind of interface will accomplish a particular task or family of tasks.

The OOP and Design Pattern Programmer has a Split Personality

To be a good programmer in OOP and design patterns, I think you need to have two very different sides of the tight and loose programmer. On the one hand, you need to know your code to write clear, efficient, and effective algorithms. On the other hand, you need to know how to write code that interacts with other code but is not made up of that code.

Perhaps one of the most important elements of Class Diagrams is the set of lines that show the nature of the relationships between classes. These lines represent code within one or both classes that allow them to work together to accomplish a task. More importantly, though, they represent the ability of the structure to encompass change and update without having to rebuild the application. This is accomplished with tight coding of objects and loose coupling.

In the first installment of the Wrong Way Warrior, we saw how an OOP developer put together a simple proof-of-concept using what he thought was a prudent approach to a battle simulation. He’d provide the Warrior with certain characteristics and then subclass those characteristics to concrete warriors that would share the capabilities of the parent class. In addition, the concrete warriors would be given a movie clip representation of the warrior.

After the first design was sent to the customer, the response was less than favorable. It was described as “a children’s game” at best. The military advisor described it as a caveman battle plan where all of the combatants are similarly armed with a club to attack adversaries. The problem was that it was bound to a fairly static design, and it would be impossible to be used for a simulation that had more complex behaviors. However, the other submissions were not much better, and so the customer provided a simple organization within the military to simulate—the basic infantry platoon. After all, they’re paying your company $1.5 million to develop the simulation. (This was news to the developer!) Figure 1 shows the organization in terms of a new set of movie clips:

Figure 1: Movie clip representation of platoon

As you can see, far from being a herd of cavemen with clubs, each of the members of the platoon has a specific role. A lieutenant with the aid of an experienced platoon sergeant runs the show. A radio operator keeps in contact with the higher-level organization (company) and other assets than can be brought to bear (e.g. artillery and air support). Broken down into four squads, 3 rifle squads and a weapons squad, the organization is fairly generic of those in the US Army and is instructive for some more complex (and realistic) applications in Flex and Flash.

What Varies?

To get started, it helps to have some kind of perspective on the problem. If we look at the basic military hierarchy, we can get an idea:

Can the simulation be expanded even to company size? The sample platoon is set up for 38 soldiers, and the Company for between 62-190, depending on specialized assignments. These are only the combat units and do not include such service and support units as medics, transport, military police and other service units.

In looking at Figure 1, we can immediately see that roles vary. Put another way, their behaviors vary. Initially, a single Warrior class was used and subclasses of Red and Blue classes made up two opposing sides. However, other than the appearance of their movie clip icons, they were identical. If we added more and more functions, we’d have to override virtually ever other method. So, we need another way.

For this round of development, we need to think about one of the first principles of design patterns,

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

Since we’ve identified that behaviors vary because of the different roles (not a bunch of undifferentiated cavemen with clubs), we’ll start with the weapons and firing behavior. We’ll put the behaviors into an interface and set up implementations of the different weapons. At the same time, we’ll set up the Warrior class so that they can use the different weapons through composition. That is, each instance of each subclass will have a different weapon to use instead of the weapon and its related behavior as an integral part of the particular Warrior class.

Sound On!

To see where all of this is leading turn up your sound and click the Play button. You will see different organizational options when you press the buttons along the top. When you click on the individual “soldiers”, they will play a sound representing their weapons. In the case of the officer and NCO’s, the entire unit’s weapons fire simultaneously representing commanded fire. Because the anti-armor and machine gun units require two people to use the weapons, clicking either of the two sprites serve to fire the weapon. After you’ve had a look, download the files—only selected few were placed in this post.

To kick things off we’ll be looking at a very simplified Warrior class and an interface for firing weapons shown in the following code:

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

//Warrior abstract class
package
{
	import flash.display.Sprite;
 
	//Abstract class. Do not instantiate
 
	public class Warrior extends Sprite
	{
		protected var fire:Fire;
		//protected var movement:Movement;
		//protected var comm:Communicate;
	}
}
 
//Encapsulating behaviors
package
{
	interface Fire
	{
		function fireWeapon():void;
	}
}

Those two elements should be viewed as structuring elements that help guide the development of the program. The Warrior abstract class includes a reference to the Fire interface and the set of behaviors that will be derived from implementations of that interface. The concrete Warrior classes will not derive their behaviors from the parent class but from the aggregate relationship between the Warrior interface (abstract class) and the Fire interface. (You can see two commented out variables, movement and comm that I’ll be referring to in a later post, but they can be ignored for the rest of this post.)

Different Characters and Behaviors

If you’ve ever been admonished to differentiate between a bad action and a bad person you’ll understand what’s going on here. The person belongs to the Warrior class and the action belongs to the Fire interface. They have the relationship shown in Figure 2:

Figure 2: Class diagram of Warrior and Fire

As you can see in Figure 2, all of the algorithms for weapons actions are encapsulated in the Fire implementations. The Warrior subclass objects get their behaviors through the Warrior interface through the Fire interface.

Marrying the Warrior to the Action

In bringing together the behavior and character, you’ll be glad to know there’s no bridezilla in the coupling. In fact, to quote another fundamental OOP principle,

Objects should be loosely coupled.

So even better, by having loosely coupled objects, when something changes, there won’t be a collapse in the entire system just in case a particular coupling doesn’t work as planned.

In Part I of The Wrong Way Warrior, the developer used movement with buttons to illustrate how each instance inherited the ability to move on the screen. This time around, the developer is demonstrating how the different types of soldiers carry out a behavior—firing a weapon—that is composed into his object through aggregation. So, instead of shooting up the screen, this time the developer decided to use sound effects of the different weapons. Also, to fire the weapons, instead of having another set of buttons, clicking on individual concrete Warrior objects launches the appropriate sound effects.

As noted above, the concrete Warrior objects are coupled with a Fire implementation, and as you will see, they’re very similar. In that respect they’re interchangeable; and that’s just what we want. Starting off, the following listings show the Rifleman (RifleMn) character and the FireRifle behavior.

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

//Creates concrete Warrior instance
package
{
	import flash.display.Sprite;
	import flash.events.MouseEvent;
 
	public class RifleMn extends Warrior
	{
		//Rifleman is movie clip in Library
		private var rm1:Sprite=new Rifleman();
 
		public function RifleMn(fx:uint,fy:uint):void
		{
			rm1.x = fx,rm1.y = fy;
			rm1.addEventListener(MouseEvent.CLICK, fireNow);
			addChild(rm1);
		}
 
		private function fireNow(e:MouseEvent):void
		{
			fire = new FireRifle();
			fire.fireWeapon();
		}
	}
}
 
//Implements Fire behavior
package
{
	public class FireRifle implements Fire
	{
		import flash.media.Sound;
		import flash.media.SoundChannel;
		import flash.net.URLRequest;
 
		private var url:String = "WeaponSounds/M16.mp3";
		private var weapon:SoundChannel;
 
		public function fireWeapon():void
		{
			var urlReq:URLRequest = new URLRequest(url);
			var gun:Sound=new Sound();
			gun.load(urlReq);
			weapon = gun.play();
			trace("Firing M16--1 shot burst");
		}
	}
}

The concrete Warrior selects a movie clip that represents its character first. Typed as a Sprite, it is used as a clickable event generator. In this case, the MovieClip object is named, Rifleman. The Rifleman instance is event-linked to a function fireNow() which then uses the fire object inherited from the parent class—Warrior. Using the fire object, the program instantiates the particular implementation of the behavior. In this case, it wants an instance of FireRifle. Keep in mind that fire inherited from Warrior is typed as a Fire object—only committing to the interface. This allows any implementation of the interface and its methods.

In looking at the Fire implementation of FireRifle, it basically sets up the sound file that is played. However, it only represents any algorithm that could be placed there instead. For example, it could be used in an algorithm to measure the expenditure of force against a target and keep track of the amount of ammunition a concrete Warrior instance expends and has remaining.

When you download and look at the different classes, you’ll see they’re pretty similar. However, some characters, like the Lieutenant, have a much more robust use of the Fire implementations 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
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

package
{
	import flash.display.Sprite;
	import flash.events.MouseEvent;
 
	public class Lieutenant extends Warrior
	{
		//Lieut is movie clip in Library
		private var lt1:Sprite=new Lieut();
 
		public function Lieutenant(fx:uint,fy:uint):void
		{
			lt1.x = fx,lt1.y = fy;
			lt1.addEventListener(MouseEvent.CLICK, fireNow);
			addChild(lt1);
		}
 
		private function fireNow(e:MouseEvent):void
		{
			//Fire Personal Weapon
			fire = new FireRifle();
			fire.fireWeapon();
 
			//PlatoonFire
			squadFire();
			weaponsSquadFire();
			squadFire();
			squadFire();
		}
 
		private function squadFire():void
		{
			//Fire Team 1
			fire.fireWeapon();
			fire.fireWeapon();
			fire = new FireSAW();
			fire.fireWeapon();
			fire = new FireGrenade();
			fire.fireWeapon();
 
			//Fire Team 2
			fire = new FireRifle();
			fire.fireWeapon();
			fire.fireWeapon();
			fire = new FireSAW();
			fire.fireWeapon();
			fire = new FireGrenade();
			fire.fireWeapon();
		}
 
		private function weaponsSquadFire():void
		{
			fire=new FireMG();
			fire.fireWeapon();
			fire.fireWeapon();
			fire=new FireRocket();
			fire.fireWeapon();
			fire.fireWeapon();
		}
	}
}

As you can see, the Lieutenant fired every weapon in the platoon, as did the Platoon Sergeant. This illustrates how flexible this design is. Because the behaviors are separated from the objects that use them, you can put them in any combination you want.

The Client

If you look at the Client carefully, you’ll see no reference at all to the Fire operations. That’s because the concrete Warrior objects all access Fire behaviors themselves. There’s no reason (nor would you want one!) to implement a concrete Fire object from the Client directly. Client constructor creates buttons used to display different arrangements of the troops. The bigger problem was getting rid of one configuration when another had been placed on the stage. Keith Peters provided a handy algorithm for clearing all children, and so I put it in the piedPiper() function that clears everything—including the buttons! So the piedPiper() method replaces the buttons after blowing them and the rest of the children off the stage.

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
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170

package
{
	import flash.display.Sprite;
	import flash.events.MouseEvent;
	import fl.controls.Button;
 
	public class Client extends Sprite
	{
		private var rocketBtn:Button=new Button();
		private var mgBtn:Button=new Button();
		private var ftBtn:Button=new Button();
		private var sqBtn:Button=new Button();
		private var hqBtn:Button=new Button();
 
		private var lieut:Warrior;
		private var platoonSgt:Warrior;
		private var radio:Warrior;
		private var sqLdr:Warrior;
 
		private var tmLdr:Warrior;
		private var sawMan:Warrior;
		private var grenMan:Warrior;
		private var rifMan:Warrior;
 
		private var tmLdr2:Warrior;
		private var sawMan2:Warrior;
		private var grenMan2:Warrior;
		private var rifMan2:Warrior;
 
		private var mgunner:Warrior;
		private var asstMgunner:Warrior;
 
		private var rocket:Warrior;
		private var asstRocket:Warrior;
 
		public function Client()
		{
			ftBtn.addEventListener(MouseEvent.CLICK, fireTeam);
			ftBtn.label = "FireTeam";
			ftBtn.x = 10,ftBtn.y = 10;
			addChild(ftBtn);
 
			sqBtn.addEventListener(MouseEvent.CLICK, squad);
			sqBtn.label = "Squad";
			sqBtn.x = 120,sqBtn.y = 10;
			addChild(sqBtn);
 
			mgBtn.addEventListener(MouseEvent.CLICK, mgCrew);
			mgBtn.label = "Machine Gun";
			mgBtn.x = 230,mgBtn.y = 10;
			addChild(mgBtn);
 
			rocketBtn.addEventListener(MouseEvent.CLICK, rocketCrew);
			rocketBtn.label = "Anti Armor";
			rocketBtn.x = 340,rocketBtn.y = 10;
			addChild(rocketBtn);
 
			hqBtn.addEventListener(MouseEvent.CLICK, hq);
			hqBtn.label = "Headquarters";
			hqBtn.x = 450,hqBtn.y = 10;
			addChild(hqBtn);
		}
 
		private function fireTeam(e:MouseEvent)
		{
			piedPiper();
 
			tmLdr = new TeamLdr(300,424);
			addChild(tmLdr);
 
			rifMan = new RifleMn(428,338);
			addChild(rifMan);
 
			sawMan = new SAW(480,424);
			addChild(sawMan);
 
			grenMan = new Grenadier(428,512);
			addChild(grenMan);
		}
 
		private function squad(e:MouseEvent)
		{
			piedPiper();
 
			sqLdr = new SquadLdr(82,300);
			addChild(sqLdr);
 
			tmLdr = new TeamLdr(300,424);
			addChild(tmLdr);
 
			rifMan = new RifleMn(428,338);
			addChild(rifMan);
 
			sawMan = new SAW(480,424);
			addChild(sawMan);
 
			grenMan = new Grenadier(428,512);
			addChild(grenMan);
 
			tmLdr2 = new TeamLdr(420,162);
			addChild(tmLdr2);
 
			rifMan2 = new RifleMn(548,76);
			addChild(rifMan2);
 
			sawMan2 = new SAW(600,162);
			addChild(sawMan2);
 
			grenMan2 = new Grenadier(548,250);
			addChild(grenMan2);
		}
 
		private function mgCrew(e:MouseEvent)
		{
			mgunner = new MG(520,500);
			addChild(mgunner);
			asstMgunner = new AssistantMG(550,570);
			addChild(asstMgunner);
		}
 
		private function rocketCrew(e:MouseEvent)
		{
			rocket = new RocketMan(650,250);
			addChild(rocket);
			asstRocket = new AssistRocket(700,300);
			addChild(asstRocket);
		}
 
		private function hq(e:MouseEvent)
		{
			lieut = new Lieutenant(132,98);
			addChild(lieut);
			platoonSgt = new PltSgt(66,188);
			addChild(platoonSgt);
			radio = new RadioMan(194,188);
			addChild(radio);
		}
 
		private function clearFireTeam()
		{
			removeChild(tmLdr);
			removeChild(sawMan);
			removeChild(grenMan);
			removeChild(rifMan);
		}
 
		private function clearSquad()
		{
			clearFireTeam();
			removeChild(sqLdr);
			removeChild(tmLdr2);
			removeChild(sawMan2);
			removeChild(grenMan2);
			removeChild(rifMan2);
		}
 
		private function piedPiper()
		{
			while (numChildren > 0)
			{
				removeChildAt(0);
			}
			addChild(ftBtn);
			addChild(sqBtn);
			addChild(mgBtn);
			addChild(rocketBtn);
			addChild(hqBtn);
		}
	}
}

If you run the program from within the Flash/Flex IDE, you should be able to see trace statements in the Output window as well to tell you what’s going on—in addition to the sound effects.

The Next Steps

I doubt there’s anyone who’s read this blog who doesn’t recognize the design pattern in use; so I won’t go into that. However, this project is yet to be completed. That will come in future posts. Now that we’re on the right track, we (that means you as well) can envision what other behaviors—or class of behaviors and their accompanying algorithms—could be added to the current set.

If you’re interested in game development, I hope that this little demonstration has shown the practicality of using design patterns and how easy they can make it. This is especially true as your projects become more complex. You might also want to review Chapter 13 of our book where we cover the Symmetric Proxy Pattern. There you will find a solution to the problem of simultaneous movement and multi-person play over the Internet using Flash Media Server. Setting up a platoon or even squad level game using simultaneous movement would be a lot of fun, and you could use several of the design patterns we discussed on this blog and in our book.

In previous posts I’ve admitted to being an algorithm junkie, and for the last several days that’s exactly the habit I’ve been feeding. Since I was documenting SSAS—ActionScript 1.0— which has no user classes or typed data, I can say with a straight face that I really didn’t have a lot of choice. However, the client side work with AS 3.0 could have been more OOP-like and maybe a little Strategy pattern could have been used just to get everyone off on the right foot.

Let’s face it, though, if someone is trying to learn how to work with a class, no matter what version of ActionScript, they don’t need it to be couched in a design pattern or OOP. I’ll often see some convoluted program that the documenter hopes to show off his/her programming acumen while explaining how to use a particular class with its properties, methods and events. Eventually, the long-suffering reader may finally (if ever) get what the documentation is trying to get across, but an easier route would have been to create a straightforward example the user can use. The developer is either going to use it in an OOP/DP context or not regardless of an example’s structure.

Clear and Simple are not the Same

In working with the documentation, I created a big fat string that contained data from a Web service and was sent from the server to a callback function on the client side. Once the client got the data, it had to be taken apart and broken into elements to be placed into an array. Since I was making the example for documentation, I wanted it to be fairly simple. The Web service delivered data in the form of a series of strings, and these small strings were concatenated into a single large string. The concatenated string kept the chunks of information from the Web service separated with tildes (~). The server-side program sent the concatenated string to the client. So all I had to do was to split up the string into array elements and run out the data to a text object using the tile (~) to re-establish the original categories on the client. I used the following ActionScript 3.0 method:

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

//The webser parameter is a concatenated string from
//Web service sent from Flash Media Interactive Server
 
private function serviceReport(webser:String)
{
	var serviceArray:Array=webser.split(/~/);
	txtArea.text = "";
	for(var serInfo in serviceArray)
	{
		txtArea.appendText(serviceArray[serInfo]+"\n");
	}
}

In and of itself, the method and accompanying algorithm are no great shakes, but since I don’t spend a lot of time breaking down big strings into array elements, I had to re-learn how to do it. Obviously I could have strong-armed it by iterating through the string and pushing chunks of it onto the array. That would have gotten it done, but I remember when I whined loudly to Adobe to include Regular Expressions in ActionScript. Well, they did and it wouldn’t be right of me to not use them. (Perl programmers write symphonies in Regular Expressions, but a lot of us mere mortals have to re-educate ourselves in the damned things every time we use them.) Then I dug up the split method which I had “remembered” as having something to do with arrays; however, it turns out the method is actually a string method to break up strings into array elements. What’s more, they use Regular Expressions in their parameters; so all I had to do was to check out String.split()in the String class and use a Regular Expression to crunch the big string into array elements.

For some reason, the person writing the documentation decided to show off some slick tricks using Regular Expressions. None of the “tricks” did anything other than generate confusion because the results of the Regular Expressions did absolutely nothing of use. So, I decided on a hunch to use the regular expression, “/~/” as the split() parameter, and it worked fine—no thanks to the documentation.

My intention was not to create an example of how to turn a string into array elements but rather how to use the SSAS WebService class in ActionScript 1.0 to get information from a web service and display it in a client-side object. Passing data from an ActionScript 1.0 object to an ActionScript 3.0 object involves a series of steps that must be handled in a certain way, and sometimes these steps are a little tricky—especially when using web services from remote servers and then passing them through an open socket server such as Flash Media Interactive Server and then back to a display object generated by Flex or Flash.

In explaining the process if it is so simple that the developer cannot use it in a program, it’s useless.

If I describe a nail and show a picture of a nail I’ve provided a clear and simple idea of a nail, but I have not explained carpentry.

This is what I mean when I say that sometimes simple is not the same as clear. Likewise, a pithy set of examples can be as confusing as something long and convoluted— check out Rube Goldberg to visualize convolution. (Oddly, Goldberg’s creations have a clean water clarity from the starting point to the end result—convoluted as they may be.)

The examples of working with class procedures are the trees of programming in that they are algorithms encapsulated in methods. However, the procedures for these algorithms sound more like forests—or even dense jungles—in some cases. With the busy programmer or student of programming (which to some extent we all are and will continue to be), how do we ever get to OOP or Design Patterns when dealing with some fairly complex algorithms in the first place?

Levels of Abstractions

One image of separating levels of abstractions is with a single head of cattle and a herd. Further arranging the cattle, we can imagine the cattle organized in corrals. From space, the corrals look like specks, and several corrals organized into a ranch may appear as a dot. Figure 1 gives you an idea—the picture from space shows part of Argentina’s cattle country, and some of those pixels might be corrals or ranches but the dark areas are lakes.

Figure 1: All Levels of Abstractions have Concrete Elements

A single cow (named Evita Guevara) is different from all other cows in the herd, but she is part of the herd. We can differentiate Herd A from Herd B by size, color, location or any other criteria we want. However, Cow A from Herd A may also sometimes hang out with Herd B; so Cow A in Herd A is identical to Cow A in Herd B. Or is it? When Cow A is in Herd B we can say that the character of Herd B changes but so too does Cow A because of a different Herd? Of course we can. In the same way that the same algorithm can be used in a variety of different classes, classes within a design pattern or a design patterns within a framework. Because of the context it’s in, it is transformed, but at the same time it transforms and defines the context.

Going the other way, I find that quantum computing to be informative. Some years ago I was reading about a French engineer who had successfully created a computing unit in nanotechnology where each bit was made up of electrons in three states—on (excited), off (unexcited) and both (simultaneously excited and unexcited). Thus, quantum bits (called qubits) can be 0 or 1, or both 0 and 1 at the same time—superposition. Ternary computer systems with the extra state have an exponential effect on computing capacity, which can further enhance computing, but in order for them to be useful to programmers, the organization of states needs to be codified in such a way that they can be employed. To compare the Ternary (sometimes called Trinary) numbers with Binary numbers in a four-bit register, click the Play button, and the Download button to download the code.

Currently, the “tree” of computing is the binary numbering system using the base 16 hexadecimal as the following set of numbers illustrates what can be placed in a 4-bit unit of computing space.

01-0000-0
02-0001-1
03-0010-2
04-0011-3
05-0100-4
06-0101-5
07-0110-6
08-0111-7
09-1000-8
10-1001-9
11-1010-A
12-1011-B
13-1100-C
14-1101-D
15-1110-E
16-1111 –F

Using 8-bit bytes, 256 different combinations (00 to FF) are possible. (Obviously, the more bytes used, the more combinations.) In a simple 8-bit computing environment, such as the 6502 processor (used in the early Apple computers), the next step up from the bit combination of 1s and 0s, was machine language that substituted hexadecimal values for operations. For example the following machine code stores the contents of the accumulator into an absolute address 7A4B.

    8D 4B 7A

The 8D value is more easily understood as the opcode, STA, which stands for “Store the contents of the accumulator in an address.” So now, you have,

    STA $7A4B

Suppose the contents of the accumulator create the string—“Hello.” The string is then stored in the address 7A4B. Just to make it simpler, suppose that we give a name to the address 7A4B and call it “Greeting.” So now we can say,

    Store the string “Hello” in the address named “Greeting.”

Another way we could state it would be,

    Greeting=”Hello”;

The engineering and programming behind the process is far more complex than explained here, but what we’re looking at is programming being built from one level of abstraction to another. (If you haven’t read the Pulitzer Prize winning book, The Soul of a New Machine by Tracy Kidder, you’re in for a real treat on creating a new miniprocessor chip (before microprocessor chips, they had the miniprocessor chips). After the project was over, one of the developers moved to Vermont where he wanted to

…deal with no unit of time shorter than a season.

Move Up to OOP

Having done a project where I microcoded a 4-bit robot microprocessor to interface with an 8-bit computer, I can tell you that coding in 0s and 1s is tedious. The machine language using a base-16 numbering system, while a lot better, was nowhere near as easy as using an assembler—really “high level” abstraction using opcodes. Of course, a higher level assembly language like Forth was even better, but involved far more coding than languages like C++ and certainly BASIC. ActionScript 3.0 seems to be about the same level of abstraction as Java and is empowered to work with more abstract concepts like classes and namespaces.

Having started on the binary level, which is one abstraction up from logic gates and electrical impulses, we’ve come to ActionScript 3.0 where we can use a single statement like,

    String.split(/~/);

to parse a giant string and turn the chunks into array elements. Granted you have to know a thing or two about Regular Expressions and the right method to employ along with the class that the method is associated with. However, it’s a lot easier than even thinking about doing that in a lower level language such as assembly language. Furthermore, by understanding ActionScript 3.0 (or any other language), the more you know about it, the more you can use the built-in operations to code even less.

When we talk of classes we’ve really talking about objects. As an object, we can make the class do a lot of things for us, but in order to use it we need to understand its properties and methods and any associated events. To some extent, there’s a tradeoff between the amount of time we need to study or use a class or a namespace and how useful it becomes. However, the fact that we can work with classes and their properties, methods and events, is a big clue that the language has moved to a higher level of abstraction.

Principles Are The Highest Level Of Abstraction

Keeping in mind that one level of abstraction is nothing more than an abstraction we can think of any level as abstract or concrete as any other. Thus, what are the trees and what are the forests changes with the level of abstraction. To be successful in programming is to be able to relate to different levels of programming abstractions. For the most part, we’d think that if we stuck with the IDE we’d be on a pretty firm base. That’s true until the IDE takes a drastic turn. The utility of the old Normal Mode in the Flash IDE drastically changed when ActionScript files were introduced. Likewise, with the advent of Flex, the IDE changed yet again from Flash to Flex for many developers.

Further, I don’t think that any developer who sticks with a single language is going to be too successful overall. Most ActionScript 3.0 developers I know are functionally knowledgeable in at least one middleware language like PHP, ASP.NET (C# or VB), ColdFusion or even Perl. Likewise, a lot of ActionScript developers work with Flash Media Server, and more and more are coming to ActionScript 3.0 via Java and C++.

By the same token that wrapping oneself in a single language is not a good career plan, I don’t think that holding on to a single design pattern is going to serve one too well either. I admit that I tend to do most of my work with the State, Strategy or Factory Method patterns, but as I begin to run into different kind of programming challenges, I start seriously reviewing the whole list of patterns. Further as Ian Cooper of CodeBetter.com points out, marrying a single framework isn’t such a hot idea either. While some frameworks, such as MVC, seem to be more stable than others, they too change and mature as witnessed in PureMCV. However, as Cooper notes, companies like Microsoft seem to have weekly frameworks and trying to keep up with them can be an exercise in futility not to mention taking time from better uses of your programming time.

Cooper suggests that the key to being a good programmer for any company, regardless of the framework du jour, is a solid understanding of OOP principles. Whether you should spend your time learning more about Cairngorm or Mate is pertinent insofar as a specific company is concerned (you’re up for a job interview and one of the requirements is knowing Cairngorm or Mate); however, overall, it’s less important than knowing the principles on which both are based—good OOP. Assuming you have a good handle on your development IDE and its toolkit, picking up a framework is certainly important, and a good foundation framework is MVC and derivations like PureMVC. However, where you see familiarity with Xframework in a job description, if you have a good sense of what the general principles are, you can familiarize yourself with a framework without having to memorize it.

Sliding Up and Down the Abstraction Pole: The Music Scan

During my preparation for an instrument rating in flying, one of the techniques we learned was the music scan. In instrument conditions (i.e., weather conditions that prevent visibility), pilots have to rely on their flight instruments. One of the dangers that pilots encounter while flying by Instrument Flight Rules (IFR) is fixating on a single instrument. For example, if you focus on your air speed indicator, you may be heading straight into the ground if you don’t check your altimeter, climb indicator and artificial horizon. To help pilots scan all of their instruments, they taught us to think of scanning the instruments as conducting an orchestra, humming ah-1 and ah-2 and scan all of the relevant instruments in an inverted “V” pattern. This may sound silly, but if you’ve ever encountered turbulence on a commercial flight, your attention can easily be fixated like a deer caught in headlights (AKA, “scared stupid”). For pilots of small planes that turbulence is multiplied several times and they’ll often fixate on one instrument while being shaken wildly. (Think of a coffee can containing a single marble being rattled by a crazed giant.)

In programming, we can be in danger of doing the same thing—fixating on a single level of abstraction. Rarely do we have to dip down to the level of assembly programming or even think about the binary logic that underlies our programs. The very best programmers I know will look at a problem from several different perspectives and on different levels of abstraction. OOP Principles are relevant to all layers of abstraction, but in particular from the level of operations on up to frameworks. In many ways, good programmers seem to live in a principle sandwich—principles surround them on all levels of programming.

• OOP Principles
• Frameworks
• Design Patterns
• Operations
• OOP Principles

For me, the biggest trap is getting stuck in an operational level—especially when I’m in a hurry. True, I’ll think of some principles (like encapsulate everything I can), but all too often I’ll crank out what amount to operational objects. However, if I go to the next level of abstraction, Design Patterns, all too often I’ll start with a Strategy pattern because its variation is an algorithm—too big of a temptation for an algorithm junkie. I suppose that’s an improvement since everything used to be State patterns. Likewise, I’m employing more Factory Method patterns, and so while I’m unstuck on a single pattern, I’ve still got to keep a music scan going—scanning design patterns in addition to levels of abstraction.

My next big leap is to a Framework. True, by combining design patterns, I’ve created little frameworks but I want to start with a nice simple MVC that can go into the Lunch Bucket series—a simple framework that can be taken to work. (Readers might also think about taking some of the PureMVC designs done by Chandima to work as well.) However, for the most part I’ll be sliding between the operational and design pattern levels. It’s not that frameworks of too abstract, but often they’re a bit too purpose oriented, and I like the granularity of design patterns. However, if I can find the right framework for the kinds of things that I typically do, I’ll adopt it—or develop a framework of my own.

Keep on Humming

As long as you force yourself to think about different levels of abstraction—a music scan of programming levels—you’ll be able to escape fixation on a single level. Abstractions are as concrete or abstract as you make them because ultimately they constitute perceptions. The OOP Principles seem to work pretty well from an operational level to a framework level, and that pretty much describes what we actually do in programming. Back in the day when I spent about 10 years with engineers from General Dynamics at weekly Forth meetings, I’m reminded of their insistence that C++ was a sham because it really wasn’t reusable code as promised. It worked differently with different processors, and only a language on the level of Forth could be trusted to do the right thing because with Forth you could program right down to the metal. They felt that if you could not take advantage of the different characteristics of the different CPUs you weren’t allowing yourself the full range of possibilities of your computer.

Unfortunately (or fortunately) very few programmers ever warmed up to Forth because of its reverse Polish notation (or Postfix notation) and low-level abstraction—as noted, it was really a higher-level assembly language. I learned a lot from Forth, and some of my own programming idiosyncrasies reflect that. However, I’m far more productive and comfortable in the higher-level languages such as ActionScript 3.0. Likewise, higher-level concepts such as OOP are vital to reusable and team-built projects. When OOP concepts can be cast in design patterns, it not only provides a common language on another level of abstraction, it increases re-usability and change of the program. Frameworks, organize operations and class relations on a still higher level of abstraction.

However, getting stuck on one level of abstraction, especially on an operational level where you’re trying to get the next algorithm to work is definitely a rut. Moving up to design patterns and OOP is a small but critical step, and it becomes as concrete as the operational level once you have practiced for a while. The trick is, though, to keep moving through the levels using OOP principles as the grease on the pole that allows you to slide to different levels and adapt to different levels. So if you ever find yourself in an abstraction rut on some level, just remember, ah-1 and ah-2.