JavaScript can do Design Patterns

I’ve always liked JavaScript, but after going through this last project of creating a design pattern with JS, I find that I like ActionScript 3.0 even more than I did before. The biggest problems that I encountered with JavaScript is that different users slipped in different frameworks (e.g., Prototype.js) and didn’t seem to mention it. My goal was to create a JS design pattern with pure unadulterated JavaScript—not using JQuery, JSon or some other helpful framework. Now, don’t get me wrong—I appreciate a good framework as much as the next guy. However, when I’m trying to create a design pattern for a general language like JavaScript, I’d rather not have to have readers run out and get one framework or another. I wanted this to work with Plain Vanilla JavaScript. So that’s what you’re going to get.

To get started, I took a look at some articles on JavaScript and classes, inheritance and OOP in general. Then I looked at some implementations of JavaScript with a Chain of Responsibility pattern. A lot of them didn’t make a bit of sense, and that’s when I realized that they were slipping in different “helpers,” and so I went back to the most basic JavaScript OOP I knew of–the 1999 book, JavaScript Objects by Nakhimovsky and Myers. Starting there, I pretty much followed that Chain of Responsibility pattern we had in Part I of this two-part series. However, instead of a mobile browser detector, I created a “Help Desk.”

Before continuing, take a look at the “Help Desk” app made with the JS CoR:

Figure 1: JavaScript Chain of Responsibility Help Desk

Inheritance is a ‘IS-A’

First I made an abstract Handler class using a single concrete and single abstract method. It seemed to me that classes in JavaScript could be abstract simply by adding a method with no content. I came up with the following class:

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

function Handler()
{ 
	//Handler 'abstract class'
} 
 
Handler.prototype.setSuccessor=function(successor)
{ 
	this.successor=successor;
} 
 
Handler.prototype.handleRequest=function(req)
{ 
	//Abstract method overridden in concrete implementation
}

I realize that it looks strange compared to more mature OOP languages like ActionScript 3.0 (not to mention Java and C++), but remember, I’m using pure native JavaScript. You create the class by the simple expedient of a function. Then, I create the methods for the class by using a Class.prototype. The class Handler now has the setSuccessor and handleRequest methods, just as we had in the ActionScript 3.0 version. So, while it looks a little goofy for creating classes and their methods and properties, that’s how it’s done.

So far so good, and it’s not rocket science. However, the next part gets a little dicey and may pop a few brain nodes. When you extend a class in JavaScript, you first instantiate the parent class. As we all know, you do not instantiate abstract classes or any other interface. They’re extended or implemented. However, that’s not the case with JavaScript. Take a look at this first child class of Handler:

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

//AS3DP inherits handler
AS3DP.prototype= new Handler();
 
function AS3DP()
{
	//AS3DP 'class'
}
 
AS3DP.prototype.handleRequest=function(req)
{
	this.req=req;
	if(this.req=="as3dp")
	{
		document.write("Naturally you want to read <em>ActionScript 3.0 Design Patterns</em> and visit our blog at as3dp.com.");
	}
	else if(this.successor != null)
	{
		document.write("Not AS3DP<br/>");
		this.successor.handleRequest(this.req);
	}
}

If you recall, basic design pattern principles, a child class “Is-A” parent class. When a JavaScript object (like AS3DP) is instantiated, it is done by declaring itself as a new Handler(). So rather than becoming a child of the parent through extension, JavaScript uses the object prototype to declare itself as an instance of the parent. It’s actually easier to see that a child class indeed “Is-A” parent because the prototype declares itself as such.

As we have seen, the methods and properties have been created outside of the class constructors. Instead of being in the class, they are in the prototype. For now, you can think of the class as the “concept of an object” and it creates and stores the properties for that concept in prototypes. So, knowing that, we can create the rest of the concrete handlers:

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

//Game inherits Handler
Game.prototype= new Handler();
 
function Game()
{
	//Game 'class'
}
 
Game.prototype.handleRequest=function(req)
{
	this.req=req;
	if(this.req=="game")
	{
		document.write("As the states change, you want a good state machine like the State Design Pattern.");
	}
	else if(this.successor != null)
	{
		document.write("Not State pattern<br/>");
		this.successor.handleRequest(this.req);
	}
}
 
//Algorithm inherits Handler
Algorithm.prototype= new Handler();
 
function Algorithm()
{
	//Algorithm 'class'
}
 
Algorithm.prototype.handleRequest=function(req)
{
	this.req=req;
	if(this.req=="algorithm")
	{
		document.write("The Strategy Design Pattern lets you access different algorithms directly without having to use conditional statements!");
	}
	else if(this.successor != null)
	{
		document.write("Not Strategy pattern<br/>");
		this.successor.handleRequest(this.req);
	}
}
 
//Factory inherits Handler
Factory.prototype= new Handler();
 
function Factory()
{
	//Factory 'class'
}
 
Factory.prototype.handleRequest=function(req)
{
	this.req=req;
	if(this.req=="factory")
	{
		document.write("The Factory Method design pattern will unlink the request to build an object from the actual object creation.");
	}
	else if(this.successor != null)
	{
		document.write("Not Factory<br/>");
		this.successor.handleRequest(this.req);
	}
}
 
//ToInterface inherits Handler
ToInterface.prototype= new Handler();
 
function ToInterface()
{
	//ToInterface 'class'
}
 
ToInterface.prototype.handleRequest=function(req)
{
	this.req=req;
	if(this.req=="tointerface")
	{
		document.write("The first principle is to <em>Program to the interface and not the implementation.</em> When you declare a new object, type it to the object's parent class; not the object itself.");
	}
	else if(this.successor != null)
	{
		document.write("Not Program to Interface<br/>");
		this.successor.handleRequest(this.req);
	}
}
 
//Truth inherits Handler
Truth.prototype= new Handler();
 
function Truth()
{
	//Truth 'class'
}
 
Truth.prototype.handleRequest=function(req)
{
 
	document.write("You know I can't handle the truth! Go visit a muse, a swami, or 3-year old.<br/>");
 
}

As you no doubt have noticed, this Chain of Responsibility implementation is not about mobile devices and their languages. Instead, it’s a “Help Desk” that I think is more typical of what you may actually use a CoR pattern for—either in JavaScript or ActionScript 3.0.

All that’s left is to do with the JavaScript is to create instances of the different handlers and set the chain of successors. The “client” that makes the requests is the HTML5 UI.

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

//'Instantiate Concrete Handlers'
var as3dp = new AS3DP();
var game=new Game();
var algorithm=new Algorithm();
var factory=new Factory();
var tointerface=new ToInterface();
var truth=new Truth();
//Set successors
as3dp.setSuccessor(game); 
game.setSuccessor(algorithm); 
algorithm.setSuccessor(factory);
factory.setSuccessor(tointerface);
tointerface.setSuccessor(truth);

You can set up the successors in any way you want except the last one has to be to the Truth class. It has no successor and is meant to be the caboose of the chain. Before going on, place all of the JavaScript into a single file and save it as “HelpDesk.js” and put it in the same folder (directory) as the HTML5 program that follows.

The HTML5 Client

Like most work with JavScript, the UI is in HTML. This is no different. All it does is to call the top of the chain (AS3DP instance) and make a request. All of the requests look like the following:

onclick=”as3dp.handleRequest(‘algorithm’);

The click handler calls the top of the chain, and the Chain of Responsibility just chugs on through until it finds what you want. Here’s the whole HTML5 code:

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

<!DOCTYPE HTML>
<html>
<head>
<style type="text/css">
body {
	font-family:Verdana, Geneva, sans-serif;
	color:#1D232;
	background-color:#dddcc5;
	font-size:12px;
}
h2 {
	font-family:"Arial Black", Gadget, sans-serif;
	font-size:24px;
	text-align:center;
	color:#611427;
}
form {
	color:#6A6A61;
}
h3 {
	background-color:#611427;
	color:#958976;
	font-size:18px;
}
</style>
<script type="text/javascript" src="HelpDesk.js">
</script>
<meta charset="UTF-8">
<title>Billz Help Desk</title>
</head>
 
<body>
<header>
  <h2>Billz Help Desk</h2>
</header>
<article>
<header>
  <h3>&nbsp;Chain of Responsibility: JavaScript</h3>
</header>
<section> This is a simple Chain of Responsibility (CoR) application. Each button represents a different request that the CoR will handle. In this case, the help is in the form of a 'Help Desk' and the CoR finds the appropriate response to the query.<br/>
  <br/>
  <form>
    <input type=button value="Make Request" onclick="as3dp.handleRequest('as3dp');" />
    How do I learn about design patterns for ActionScript 3.0 <br/>
    <input type=button value="Make Request" onclick="as3dp.handleRequest('game');" />
    I'm making a game where states keep changing. What would be a good design pattern for dealing with changing states?<br/>
    <input type=button value="Make Request" onclick="as3dp.handleRequest('algorithm');" />
    My app involves a lot of problem solving with different algorithms? What's a good pattern for dealing with multiple algorithms?<br/>
    <input type=button value="Make Request" onclick="as3dp.handleRequest('factory');" />
    Whenever I create a new object with my Client object, I build up dependencies. Is there a pattern to avoid such dependencies?<br/>
    <input type=button value="Make Request" onclick="as3dp.handleRequest('tointerface');" />
    What is a primary guiding design pattern principle?<br/>
    <input type=button value="Make Request" onclick="as3dp.handleRequest('truth');" />
    I want to know the truth!<br/>
  </form>
</section>
<br/>
<section>The CoR pattern works sequentially so that as it moves through the chain, you can see each rejected attempt to find the correct handler. (Normally, you wouldn't see those rejected handlers.) It is a very easy pattern to update and add additional handlers.</section>
</article>
</body>
</html>

So, now you’re all set to use JavaScript for design patterns. The plain vanilla JS has limitations doing OOP, but you can harness it and bend it to your OOP will. The many different frameworks that work in conjunction with basic JavaScript will make it look more like an OOP language, but you can get by without. There’s a lot to be done with even the most unadorned JavaScript, and I tested the app on an iPhone, and it works fine. However, I’ll bet that several of you can find better ways to handle either the JavaScript or HTML5 (or both) with design patterns, and we’d like to hear from you. Naturally, if you have a favored framework that makes OOP work more efficient, let us know—even better send a design pattern example.

After Mom, Ask Dad, and then the Dog

To get started on the quest to see whether useful design patterns can be created with JavaScript, I thought it’d be a good idea to go from the known to the unknown. In this case, those familiar with this blog know ActionScript 3.0 design patterns, and the unknown (for some at least) is JavaScript. Well, I suppose just about everyone who reads this blog knows something about JavaScript, but several may not have been involved with either JavaScript OOP or design patterns. By creating an ActionScript 3.0 app using a pattern and then going through the app step-by-step, readers may be better able to understand how we might approach design patterns using JavaScript. I decided to use the Chain of Responsibility (CoR) pattern to go through the types of mobile operating systems that we examined in the previous post. In this way, we can create something both familiar and practical.

Every time I use the Chain of Responsibility pattern, I feel that I’m swatting a fly with a weapon of mass destruction. I see all of these classes, and I’m thinking that I could have done the same thing with a switch statement or something even slicker. Then I need to remind myself why I’d use the CoR in the first place.

The Chain of Responsibility separates the handling of an event from the request to handle it.

In a broader context, this allows the developer to make changes to either the request or the handling of the event without disrupting some other part of the program. It’s quite simple as well. Just imagine several people lined up with different kinds of expertise and/or authority. A request is issued, and once it reaches the person with the right expertise or authority, it is handled. The request is separated from the way it will be handled. That’s up to the expert. Figure 1 shows the class design:

Figure 1: Chain of Responsibility Pattern

Getting Started with CoR

For details about ways to setup and use CoR see our original discussion . The focal points are in the following:

• An interface (an abstract class or interface) establishes a handler operation
• Each request handler has a separate class derived from the handler interface
• Each handler class has a successor which is another handler class
• The last handler in the chain has no successor
• As soon as a handler can handle the request, the chain stops and the handler takes care of the request.

You may be thinking that this is not very efficient since it requires a sequential path. We’ve considered ways to get around a sequence (see our posts on Skip Lists), but for now we’ll stick with the traditional CoR and use a sequential search through the list of handlers.

The Chain of Mobile Operating Systems

This CoR simulates finding one of several types of mobile OS. Given the type of OS, it looks for ways to handle each one optimally. In the JavaScript version of this, we want to have it select a CSS file or another JS file to best use the kind of mobile device involved. The concrete handler classes are the objects used to deal with whatever requirements are necessary. In the example, each handler simply traces out “Set up for xxOS,” where “xx” is the found mobile OS. It also traces out which handlers were rejected so that you can better see how the chain works. Since Android is at the top of the chain, you see no rejections, while Windows CE at the bottom of the chain displays the whole chain.

It might be helpful if you take a look at the whole concept of Linked Lists. The Chain of Responsibility is something like a linked list, but instead of linking lists, it links handlers.

The Client class makes the initial request and sets up a simple requesting UI for testing the application. It makes requests using a string. I just used the lowercase ID of the main mobile OS types as the “request-to-handle.” After making the request, the “chain” takes over. In this example the top of the chain is the Android, but it could be any of the others as well. The developer has complete control over the sequence.

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;
	import fl.controls.Button;
	import fl.controls.TextInput;
	import fl.controls.Label;
	import flash.text.TextFieldAutoSize;
 
	public class Client extends Sprite
	{
		//Handlers + Request
		private var android:Handler= new Android();
		private var iphone:Handler= new IPhone();
		private var blackberry:Handler= new Blackberry();
		private var series60:Handler=new Series60();
		private var windowsce:Handler=new WindowsCE();
		private var cannothandle:Handler=new CannotHandle();
 
		//UI
		private var btn:Button=new Button();
		private var iput:TextInput=new TextInput();
		private var lbl:Label=new Label();
 
		public function Client()
		{
			setupChain();
			setupUI();
		}
 
		private function setupChain():void
		{
			//Sequence set up here
			android.SetSuccessor(iphone);
			iphone.SetSuccessor(blackberry);
			blackberry.SetSuccessor(series60);
			series60.SetSuccessor(windowsce);
			windowsce.SetSuccessor(cannothandle);
		}
 
		private function setupUI():void
		{
			//This simulates getting the mobile OS from the using system
			lbl.autoSize = TextFieldAutoSize.LEFT;
			lbl.text="Enter name of mobile device: (Use lower case.)";
			lbl.x=50,lbl.y=30;
			addChild(lbl);
			btn.x=50, btn.y=75;
			btn.label="Start the chain";
			btn.addEventListener(MouseEvent.CLICK,requestOS);
			addChild(btn);
			iput.x=50,iput.y=50;
			addChild(iput);
		}
 
		private function requestOS(e:MouseEvent)
		{
			android.HandleRequest(iput.text);
		}
	}
}

For the end of the chain, I added a “CannotHandle” class that extends the Handler interface. This functions something like a default option in a switch statement. If none of the handlers can handle the request, you need to provide the user with some kind of feedback.

The Abstract and Concrete Handlers

In this application the interface is an abstract class, named Handler. The abstract method, HandleRequest() takes a string argument and checks if it’s the appropriate class to handle the request, and if not, passes it on to the successor. The last concrete Handler object is always the CannotHandle class.

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

package
{
	//Abstract class
 
	public class Handler
	{
		protected var successor:Handler;
		protected var mobileType:String;
 
		public function SetSuccessor (successor:Handler):void
		{
			this.successor=successor;
		}
 
		public function HandleRequest (req:String):void
		{
			//Provide details in subclasses
		}
	}
}

With ActionScript 3.0, you have to make up abstract classes by including at least one method that you want to be abstract and must be overridden when implemented. In this case the HandleRequest(reg:String) method expects to be overridden. On the other hand, the SetSuccessor method that expects a concrete handler as an argument is inherited all set to use. Just add an argument. In deciding where to implement the SetSuccessor method, I decided to use the Client. In this way the developer can clearly see the order of the chain. Further, if changes are made, the CannotHandle class can easily be moved to the end of the chain without having to change the sequencing within the concrete handler classes.

The two handler properties, successor and mobileType are used to identify the successor class (object) and store the name of the operating system, respectively. All that’s left is to provide the concrete implementations which involves two steps:

1. Overidding the HandleRequest() method and adding whatever you want the class to do if it’s to handle the request.
2. Sending the search off to the successor if it cannot handle the request.

That’s not exactly rocket science. This is a very easy design pattern to implement. I added a private method to each class, sendBack() that represents a more complex handling of any request outside of the conditional statement that identifies the handler as the appropriate one for the request. The more differentiated and complex the handlers, the more that you can appreciate the CoR. You can add anything you need to handle a request without having to worry about the requester (Client) or the other ways available to handle a request. Further, when you add or change a handler to the chain, it will not disrupt the rest of the program.

The following six classes represent concrete handlers. All of them are almost identical other than having different mobile OS’s to sort out. The CannotHandle concrete handler is just a caboose the both mark the end of the chain and let the user know that his request cannot be handled. It has no successor and the sendBack() function tells the user that her request cannot be handled.

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

//Android
package
{
	public class Android extends Handler
	{
		//Concrete handler
		override public function HandleRequest(req:String):void
		{
			if (req =="android")
			{
				mobileType = "Now setting up " + req + " environment.";
				sendBack();
			}
			else if (successor != null)
			{
				trace("Not Android");
				successor.HandleRequest(req);
			}
		}
 
		private function sendBack():void
		{
			trace(mobileType);
		}
	}
}
 
//iPhone
package
{
	public class IPhone extends Handler
	{
		//Concrete handler
		override public function HandleRequest(req:String):void
		{
			if (req =="iphone")
			{
				mobileType = "Now setting up " + req + " environment.";
				sendBack();
			}
			else if (successor != null)
			{
				trace("Not iPhone");
				successor.HandleRequest(req);
			}
		}
 
		private function sendBack():void
		{
			trace(mobileType);
		}
	}
}
 
//BlackBerry
package
{
	public class Blackberry extends Handler
	{
		//Concrete handler
		override public function HandleRequest(req:String):void
		{
			if (req =="blackberry")
			{
				mobileType = "Now setting up " + req + " environment.";
				sendBack();
			}
			else if (successor != null)
			{
				trace("Not Blackberry");
				successor.HandleRequest(req);
			}
		}
 
		private function sendBack():void
		{
			trace(mobileType);
		}
	}
}
 
//Series60
package
{
	public class Series60 extends Handler
	{
		//Concrete handler
		override public function HandleRequest(req:String):void
		{
			if (req =="series60")
			{
				mobileType = "Now setting up " + req + " environment.";
				sendBack();
			}
			else if (successor != null)
			{
				trace("Not Series60");
				successor.HandleRequest(req);
			}
		}
 
		private function sendBack():void
		{
			trace(mobileType);
		}
	}
}
 
//Windows CE
package
{
	public class WindowsCE extends Handler
	{
		//Concrete handler
		override public function HandleRequest(req:String):void
		{
			if (req =="windowsce")
			{
				mobileType = "Now setting up " + req + " environment.";
				sendBack();
			}
			else if (successor != null)
			{
				trace("Not WindowsCE");
				successor.HandleRequest(req);
			}
		}
 
		private function sendBack():void
		{
			trace(mobileType);
		}
	}
}
 
//CannotHandle
package
{
	public class CannotHandle extends Handler
	{
		//Concrete handler
		override public function HandleRequest(req:String):void
		{
			mobileType = "Rats! We looked and couldn't find that mobile OS. \n"
			mobileType += "We'll just have to get to work and see if we can \ndevelop a way to handle it for you.";
			sendBack();
 
		}
		private function sendBack():void
		{
			trace(mobileType);
		}
	}
}

Testing the Chain

Figure 2: UI provides a way to test the chain.

If an OS near the end of the chain is selected, you can see all of the links in the chain used to find the correct handler. Figure 3 shows what occurs if “windowsce” is requested. Had “android” been the search OS, it would have popped up without any links in the chain showing it was not found.

Figure 3: Output showing steps in sequence and feedback.

Finally, if the request cannot be handled, an important development step is to add a handler that tells the user that his OS cannot be found. The final handler in a chain has no successor, and you definitely do not want to link back to the beginning of the chain! That would set up an infinite loop. Figure 4 shows the feedback when a request cannot be handled:

Figure 4: Feedback for an unhandled request.

JavaScript is the Next Link

In Part II, I’d like to step through these same classes using JavaScript prototype classes and see if we can use the same pattern. I think that if each concrete handler can configure the screen for a particular mobile device, it would be quite useful. As new devices are added, such as iPad, Kindle Fire, and various other tablets, you will find that the flexibility afforded by the Chain of Responsibility. To get ready for Part II, go over the ActionScript 3.0 version and make sure everything makes sense. Send in comments if you have a question.

Face the Facts: We've got to deal with Mobile

At this point in time I can easily create a script to determine whether a browser is mobile or non-mobile. I want to get to the point where I can put together a Chain of Responsibility pattern so that I have a flexible design for tweaking a specific kind of mobile device (e.g., calling up appropriate CSS). This requires OOP JavaScript, and so I had to revisit my old JavaScript work. One of the best books on both OOP and JavaScript is Javascript Objects: Object Use and Data Manipulation with JavaScript by Alenander Nakhimovsky and Tom Myers published by Wrox in 1998. It was written by a couple of professors at Colgate University and is pitched at a pretty high level that most readers of this blog will appreciate. (You can still get it from Amazon, and it’s a gem to have no matter what language you favor.) Another good book that deals with JavaScript objects is Douglas Crockford’s JavaScript: The Good Parts (O’Reilly, 2008). Crockford understands JavaScript down to the metal and has great explanations and examples.

So the question is:

Can JavaScript handle OOP and Design Patterns?

To find out, I started writing some prototype classes but found I’d have to spend some more time trying to cobble something together that was both reasonable (it maintains the DP value of flexibility, update and reuse) and real (I didn’t want to make a phony DP with hack classes.) However, it didn’t take long to put together a little code that works to filter out both different mobile devices and non-mobile devices. My plan is to take this code and change it so that I can do the same thing with a Chain of Responsibility design pattern. Here’s the code:

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

// JavaScript Document
var sniffer=new Object();
var agentNow=navigator.userAgent.toLowerCase();
sniffer.android=(agentNow.search("android")>=0);
sniffer.series60=(agentNow.search("series60")>=0);
sniffer.iphone=(agentNow.search("iphone")>=0);
sniffer.blackberry=(agentNow.search("blackberry")>=0);
sniffer.windowsce=(agentNow.search("windows ce")>=0);
var counter=0;
var flag=new Object();
flag.nonMobile=true;
for(var mobile in sniffer)
{
	if(sniffer[mobile])
	{
		switch(counter) {
		case 0:
		document.write("android<br/>");
		flag.nonMobile=false;
		break;
		case 1:
		document.write("series60<br/>");
		flag.nonMobile=false;
		break;
		case 2:
		document.write("iphone<br/>");
		flag.nonMobile=false;
		break;
		case 3:
		document.write("blackberry<br/>");
		flag.nonMobile=false;
		break;
		case 4:
		document.write("windows ce<br/>");
		flag.nonMobile=false;
		break;
		}
	}
	counter++;
}
if(flag.nonMobile)
{
		document.write("Non-mobile or unrecognized device.");
		document.write("<br/>");
}

Before you say anything (or think anything), I realize that this code is about as flexible as a rebar (AKA: reinforcing bar), and if you’re into JavaScript, you can think of 10 ways that this can be done better. However, the goal is to see if this can be refactored into a design pattern. Here’s my plan:

1. Set up a dummy Chain of Responsibility that links the different kinds of responsibilities.
2. Have each responsibility be actions taken for different kinds of mobile devices or a desktop.
3. Use JavaScript objects to do the work of the concrete handlers

However, before I get started on this project, I’d really like to hear from you and even better, see what you can do with this challenge. So between now and the next post on this topic, let’s hear from you! Also feel free to add different kinds of mobile devices such as tablets and other phone OSs.

For this blog, though, I thought I’d use a translation from one of the design patterns we have on this blog so that you can more easily see the similarities and differences between ActionScript 3.0 and PHP in implementing the same design pattern.

Chain of Responsibility

As you may recall from our Chain Of Responsibility (CoR) post, the design pattern is used when you want to have a system that takes care of requests when you have different outcomes. In our original example, we added a helper class called Request, but otherwise we stuck with the basics of the CoR structure. Figure 1 shows the class diagram of the CoR we used in our initial post.

Figure 1: Chain of Responsibility Class Diagram

In this particular design pattern the Client class is a full-fledged participant in the pattern. Because Client classes are request objects themselves, it may seem odd to have a Request class. Just think of the Request class as a helper class that encapsulates requests for the Client.

The back story to this CoR implementation is that you have a company that needs to distribute pick-up trucks using the minimum size truck for any given load. So, you set up a CoR design to check the load requirements sent in, and then dispatch the smallest possible truck for a given load. (For other details of the CoR and ActionScript 3.0, check out the original CoR post.)

The PHP implementation of CoR

Assuming you’ve looked at the original CoR post, let’s jump right in to the PHP implementation. Figure 1 shows the exact same set of classes that we’ll use with the PHP version of the design. We’ll start at the heart of the CoR with the Handler class. PHP has true abstract classes and we can create the Handler using an abstract class. (In case you’re wondering, we probably could have done the same thing with an interface, but tweaking seems easier using abstract classes.)

1
2
3
4
5
6
7
8
9

<?php
 
	abstract class Handler
	{
		abstract public function handleRequest($request);
		abstract public function setSuccessor($nextTruck);
	}
 
?>

The handleRequest() method uses an encapsulated request from the Request class that is instantiated in the Client. As you can see, PHP does not have strong typing; so the parameters are not typed. The setSuccessor() establishes the next link in the chain. If the current object (class) cannot provide what is requested, the request is passed to the successor.

For this example, three concrete Handler objects—GMC, Dodge and Ford—handle all requests. If a load is too heavy for the lightest truck, the request is passed on to the next one and so on until the request reaches the end of the chain. For this example, there’s no “too heavy” notice if the load surpasses the capacity of the largest truck, but it’d be easy to add such a notice or another class that provides remedies for loads too heavy for the largest truck. (In case you’re considering a solution, think modulo.)

The Concrete Handlers

The three concrete handlers represent the load capacities of three trucks. Each concrete handler looks at the load and if it can handle it, it says so. Otherwise, it passes the request up the line until it reaches the end of the chain or a truck with in the load parameters. The following three classes represent concrete handlers:

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

<?php
 
//GMC Class
	class GMC extends Handler
	{
		private $successor;
 
		public function setSuccessor($nextTruck)
		{
			$this->successor=$nextTruck;
		}
 
		public function handleRequest ($request)
		{
			if ($request->getPounds() < 1547)
			{
				echo ("A GMC Canyon would be good for this. Weight: " . $request->getPounds() . "<br />");
			}
			else if ($this->successor != NULL)
			{
				$this->successor->handleRequest ($request);
			}
		}
	}
?>
 
//Dodge class
<?php
	class Dodge extends Handler
	{
		private $successor;
 
		public function setSuccessor($nextTruck)
		{
			$this->successor=$nextTruck;
		}
 
		public function handleRequest($request)
		{
			if ($request->getPounds() < 1750)
			{
				echo "A Dodge Dakota can handle this load. Weight: " . $request->getPounds() . "<br />";
			}
			else if ($this->successor != NULL)
			{
				$this->successor->handleRequest($request);
			}
		}
	}
?>
 
//Ford class
<?php
	class Ford extends Handler
	{
		private $successor;
 
		public function setSuccessor($nextTruck)
		{
			$this->successor=$nextTruck;
		}
 
		public function handleRequest ($request)
		{
			if ($request->getPounds() < 1890)
			{
				echo ("This load requires a Ford 150. Weight: " . $request->getPounds() . "<br />");
			}
			else if ($this->successor != NULL)
			{
				$this->successor->handleRequest ($request);
			}
		}
	}
?>

As you can see, each link in the chain (concrete Handler class) uses a simple conditional statement to handle the request. The “handling” is merely using an echo statement to announce that a particular truck can handle the load. (In this case the Ford may be hopelessly unrealistic, but never mind.)

The Client and Request

I always like it when the Client class is named as a participant in a design pattern, and with CoR, it is a main one directly tied into the Handler. Just the Client, Handler interface, and the Concrete Handler classes make up CoR. When using PHP, you need a calling file, and so an added file calls the Client. The Request object is actually one method smaller than the original Request created for ActionScript. As a getter/setter the setter is in the Constructor function, and so it seemed redundant to add a setter method in addition to the Constructor. The getter method encapsulates the value of the request generated originally in the Client. All three files are included 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

<?php
//Request class
class Request
	{
		private $value;
 
		public function __construct($weight)
		{
			$this->value=$weight;
		}
 
		public function getPounds()
		{
			return $this->value;
		}
	}
?>
 
<?php
//Client class
class Client
{
	public function __construct()
	{
		$Acme = new GMC();
		$Paramount = new Dodge();
		$Pinacle = new Ford();
		$Acme->setSuccessor($Paramount);
		$Paramount->setSuccessor($Pinacle);
 
		// Generate and process load requests
		$loadup = new Request(1200);
		$Acme->handleRequest ($loadup);
 
		$loadup = new Request(1650);
		$Acme->handleRequest ($loadup);
 
		$loadup = new Request(1795);
		$Acme->handleRequest ($loadup);
	}
}
?>
 
<?php
//Testing file
ini_set("display_errors","2");
ERROR_REPORTING(E_ALL);
 
include_once('Client.php');
include_once('Handler.php');
include_once('Request.php');
include_once('GMC.php');
include_once('Dodge.php');
include_once('Ford.php');
 
$testClient = new Client();
?>

When you test the program, you should see the following output:

A GMC Canyon would be good for this. Weight: 1200
A Dodge Dakota can handle this load. Weight: 1650
This load requires a Ford 150. Weight: 1795

I added the input values (weight) to show that this CoR knew what it was doing. Albeit, it’s not doing much other than demonstrating the CoR structure. However, I’ve got big plans for the CoR in PHP for automatically handling inquiries. The more options available, the more useful the CoR becomes. And of course, since it’s a design pattern, adding and changing options is quite easy.

Some Differences

The biggest differences in the programs are PHP and ActionScirpt 3.0 syntax differences. Here are some you can see immediately:

• PHP uses -> instead of . for linking properties and methods to an object (e.g., myObj->myProp instead of myObj.myProp)
• PHP has no data typing
• PHP requires include for all the class files in use (in the testing file)
• All variables have dollar signs ($) in front of them
• PHP concatenation uses a dot (.) instead of a plus sign(+)
• PHP constructor functions use __construct() instead of the class name

Other kinds of differences are the idiosyncrasies of each language, and you may have to push and pull a bit when applying design patterns of one to the other. However, the nice thing about design patterns is that they are generally applicable to all languages. I had thought that lack of typing to an interface (because of the weak typing of PHP) would be a deal-breaker, but I don’t think so any more. I suppose with a very complex program, you’d miss stronger typing, but from what I’ve seen PHP programs with a good structure work well and are easy to change, are reusable and are loosely coupled. So, in case you’re considering creating PHP design patterns, I’d definitely encourage it, and you’ll find that converting examples from ActionScript 3.0 isn’t all that difficult.

Naturally, we’d like to hear from both ActionScript 3.0 and PHP developers to get your thoughts on this topic. We’d be very interested in applications that use both ActionScript 3.0 and PHP and linking up optimal design patterns so that modules from the two languages can more easily be integrated.

Chain of Responsibility Overview

Because looking at a Class Diagram is useful for seeing the larger context of the design pattern, we’ll look at it first and then go about describing its features.

Figure 1: Chain of Responsibility Class Diagram

This looks fairly simple, and at the basic level it really is. Like some of the other design patterns, the Client is part of the pattern, and so it’s integral. At the center of the pattern is the Handler interface. For the time being, think of the interface as an abstract class because that is what is used in the initial example. The abstract class includes a function for setting successors in a chain and another to handle a request. Finally, the ConcreteHandler classes represent the specific and different classes that handle requests. Generally speaking, an application would include several ConcreteHandler classes, and each is set up in a chain to deal with requests where appropriate.

Unchain My Request

In their work, the Gang of Four, illustrate the CoR using a Help desk. The Help desk is set up in a hierarchy with different Help topics. As a request moves through the hierarchy it attempts to find the concrete handler that deals with its query. Another good example (my favorite) is provided by the Freemans in their Head First Design Patterns book. Their example envisions a company that gets different kinds of email, and to sort it out, the CoR design pattern is used. It has separate handlers (ConcreteHandler) for fan mail, spam, complains and so forth. So, when an email arrives, it is automatically handled in the appropriate manner moving it along a chain. Both of these examples share the concept of uncoupling the request from the handler. In this way, both requests and handlers can be changed without disrupting the larger program. As anyone who has worked with a program to handle products or services in a rapidly changing environment knows, your design needs this kind of flexibility.

Figure 2 provides a general idea of a chain of concrete handlers set up in succession. When the request comes in, it is examined by ConcreteHandler A. If A cannot handle the request, it is passed on to ConcreteHandle B and so forth until it either runs out of concrete handlers or is handled. The different colored diamonds represent the different ways of handling a request. The process terminates once the request is handled.

Figure 2: Request Chain

If you want some kind of handler to deal with unhandled requests, the last concrete handler in the chain (ConcreteHandler E in Figure 2) could be a residual one that issues a notice informing the user that the request could not be handled. However, the alternative of simply not handling a request because the criteria for handling is not in the chain of concrete handlers is perfectly acceptale.

The Implicit Receiver

One of the two key concepts in the CoR pattern is implicit receiver. Even though the requesting object may not have any idea of which concrete handler will handle a request, the one that actually handles it is the implicit receiver. That clears up a lot of possible confusion. Given the criteria of the request, only one of the concrete handlers can meet that criteria, and so implicitly that is the receiver. It’s a simple concept but one that you need to keep in mind.

Because the request is uncoupled from the receiver, you can easily add more concrete classes to be the implicit receiver. Imagine a business with a CoR that finds items in certain price ranges. Let’s say that a merchant finds that most people will spend $50 on a project. He has handlers for under $50 and from $50 to $100. Research shows that most of the under $50 sales are actually for around $20. To increase revenue, he adds a new concrete handler that offers a $35 to $65 range. Because he used a CoR design pattern, all he needs to do is to add a handler for that range and make minor adjustments to the concrete handlers below and above that range. Because the receivers are implicit and uncoupled from the request, such adjustments are easy and the program can be changed without having to refactor the entire application.

The Successor

The second key concept in the CoR is successor. To move a request along a chain and to keep the receiver implicit, each object must maintain a common interface. The successor defines a way to move along the chain of objects and shares the same interface as do the receiver objects (concrete classes). As a result, the pattern requires some method for specifying successors in the interface but must hold the interface. In the class diagram in Figure 2, you can see the successor in the Handler interface looping back to itself.

One way of setting up this method can be seen in the interface itself. A successor object is typed as the interface (Handler). Then the method parametizes the successor object. The following snippet shows how this looks:

1
2
3
4
5
6
7
8
9

public class Handler
        {
                protected var successor:Handler;
 
                public function SetSuccessor (successor:Handler):void
                {
                        this.successor=successor;
                }
….

Each of the concrete handlers includes a way to pass on the request to the next concrete handler using the successor object .

A Minimalist Chain of Command Application

In coming up with an application, I envisioned a building contractor who needed to haul different loads to a job site. In order to save money, he wanted to use a pickup truck that would best haul a given load but no more. In that way, he would not waste money on both gas and trucks that hauled greater loads that might be needed elsewhere.

The client sends out a request with a certain load weight, and the CoR picks out the best truck for the job. It begins with the smallest truck and works up the chain until he finds a truck that optimally handles the required load. It’s a simple application, but one where you can see all of the parts working together. The application has the following components:

• Handler class that acts as an interface for the application
• Three concrete handler classes that act as receivers
• A client class that makes the request
• A request class that encapsulates the request

Handler Class
This first class acts as an interface. It is an abstract class in spirit (since ActionScript 3.0 and ECMAScript r4 have no real abstract class.)

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

package
{
	//Abstract class
 
	public class Handler
	{
		protected var successor:Handler;
 
		public function SetSuccessor (successor:Handler):void
		{
			this.successor=successor;
		}
 
		public function HandleRequest (request:Request):void
		{
			//Provide details in subclasses
		}
	}
}

As you can see, the Handler class has two methods. The first method will be used to set the successor and the second method to handle requests. However, because the request handler involves different requirements for each concrete handler, the method remains abstract in the Handler class.

Concrete Handler Classes

Because the Handler class is an abstract one, all of the subclasses must override the methods in the Handler class. The HandleRequest () method needs to communicate the limits of its ability to handle the request and pass on to its successor if it cannot handle it. The following three concrete handlers do that:

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

//GMC.as
package
{
	// "ConcreteHandler"
 
	public class GMC extends Handler
	{
		override public function HandleRequest (request:Request):void
		{
			if (request.Pounds < 1547.0)
			{
				trace ("A GMC Canyon would be good for this. Weight: "+request.Pounds);
			}
			else if (successor != null)
			{
				successor.HandleRequest (request);
 
			}
		}
	}
}
 
//Dodge.as
package
{
	// "ConcreteHandler"
 
	public class Dodge extends Handler
	{
		override public function HandleRequest (request:Request):void
		{
			if (request.Pounds < 1750.0)
			{
				trace ("Dodge Dakota can handle this load. Weight: "+ request.Pounds);
			}
			else if (successor != null)
			{
				successor.HandleRequest (request);
 
			}
		}
	}
}
 
//Ford.as
package
{
	// "ConcreteHandler"
 
	public class Ford extends Handler
	{
		override public function HandleRequest (request:Request):void
		{
			if (request.Pounds < 1890)
			{
				trace ("This load required a Ford 150. Weight: "+request.Pounds);
			}
			else if (successor != null)
			{
				successor.HandleRequest (request);
			}
		}
	}
}

The concrete handlers evaluate the weight of the request. If the request is within the range of the limit, the request is handled, but if not, the request is sent to a successor, if any. In this particular implementation of the CoR, if the weight is over 1889, the request is not handled.

Request and Client Classes

The Client class implements the request and establishes the hierarchy in the chain of command. The Request class is simply a way of encapsulating the request, which is nothing more than a number. The getter and setter methods are set up and the value for a load is paramaritized in the main method.

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

//Request.as
package
{
	// Request details
 
	public class Request
	{
		private var loadWeight:Number;
 
		// Constructor
		public function Request (loadWeight:Number)
		{
			this.loadWeight=loadWeight;
		}
 
		// Getters and Setters
		public function get Pounds ():Number
		{
			return loadWeight;
		}
		public function set Pounds (loadWeight:Number):void
		{
			loadWeight=loadWeight;
		}
	}
}

You will notice that all of the concrete handlers hold a reference to the Request class. In effect it is a mixin class used by both the Client class and ConcreteHandler classes. However, it is only instantiated by the Client class. If you feel queasy about using the Request class, you can easily change the ConcreteHandler classes to accept what amounts to a numeric literal. Then, each HandleRequest would simply accept a literal value directly rather than using the Request class.

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

//Client.as
package
{
	import flash.display.Sprite;
	// This is the Client
 
	public class Client extends Sprite
	{
		private var Acme:Handler;
		private var Paramount:Handler;
		private var Pinacle:Handler;
		private var loadup:Request;
 
		public function Client()
		{
			// Setup Chain of Responsibility
			Acme = new GMC();
			Paramount = new Dodge();
			Pinacle = new Ford();
			Acme.SetSuccessor (Paramount);
			Paramount.SetSuccessor (Pinacle);
 
			// Generate and process load requests
			loadup = new Request(1200);
			Acme.HandleRequest (loadup);
 
			loadup = new Request(1650);
			Acme.HandleRequest (loadup);
 
			loadup = new Request(1795);
			Acme.HandleRequest (loadup);
		}
	}
}

In looking at the Client class, all of the request objects are typed as the interface—Handler rather than to a concrete class. Then, each instantiates a concrete handler, and sets up the succession. Three different request values should test each of the three concrete classes’ ability to recognize itself as the implicit receiver.

The Client also begins each request with the object that is at the beginning of the chain of responsibility. The smallest load is handled by the GMC class, and so the instance of that class (Acme) is always used to send out a request.

When you test the program, you will get the following output:

A GMC Canyon would be good for this. Weight: 1200
Dodge Dakota can handle this load. Weight: 1650
This load required a Ford 150. Weight: 1795

Each of the three requests was handled by the appropriate concrete handler. Even better, if new kinds of requirements or requests are brought in, the changes are only in the concrete handlers.

Reader Challenge

As usual I’d like any feedback as far as improving the application, but more importantly, I’d like to see three added concrete handler classes. Here’s what they are:

• A lower base weight of 500 pounds for a mini-pickup.
• A mid-size weight that can be inserted between the Dodge and the Ford
• A class that would respond to the fact that the load weight they requested is too big for any of the available trucks.

If the CoR design pattern has the kind of flexibility advertised, this ought to be a snap.