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.

PHP, My Old Friend

PHP has always been a developers programming language. From its inception, you could write PHP using Notepad or TextEdit and not have to worry about some cranky API or IDE. Alternatively, there are plenty of development applications for creating PHP, such as Dreamweaver. Further, you could write email apps as easy as a ‘Hello World’ example. Not only is PHP open source, it is constantly updated and improved by developers working on it because it is important to them. You can plunk it down on top of an Apache server (also open source) and use MySQL (also open source—but maybe not for long) for a database. It runs on Linux, Windows and on Mac OS (it comes standard with Macs as does an Apache server). Further, PHP 5 has real abstract classes! What’s not to like?

Working with Design Patterns in PHP

Not to raise the ire of PHP programmers, but working with design patterns in PHP after getting used to doing so in ActionScript 3.0 (or Java or C#) can be a real challenge. In fact working with OOP principles in a language without typed data can be extremely perplexing. This is not due to the lack of PHP design pattern examples or OOP discussions by top-notch programmers. I found plenty. Rather, when I started working on the PHP portion for the recent Design Patterns at Work Survey, I found many unexpected hitches. Naturally, I didn’t want to create a survey on design patterns and not use a design pattern to create it. It was a simple Strategy pattern, but still, it was important to do it with some modicum of integrity. What follows are some of my discoveries and queries about working with PHP where OOP and design patterns are important.

How Can You Program to an Interface Without Typed Variables?

For Gamma, et al the first principle for minimizing dependencies in programming is,

Program to an interface, not an implementation

In ActionScript 3.0 you have something like the following in programming to an interface:

var instanceNow:MyAbstractClass = new ConcreteClass();

Likewise in Java and C#, you’d see,

MyAbstractClass instanceNow = new ConcreteClass();

All of these languages have strict typing. So how is it possible in PHP— characterized by loose typing—to program to an interface? In looking at numerous examples, all I saw was typing to the implementation. To illustrate, the following example shows building an abstract class with an abstract property and method. To understand this example in PHP, you need to know a couple of things:

• The => operator is the same as a dot (.) in ActionScript 3.0. So
     $keyInstance->keyMethod()
  in PHP is the same as
     keyInstance.keyMethod()
  in ActionScript 3.0.
• Variables begin with a $ character. However, when expressed as properties of an object, they do not have the $ character.
• Variables have no typing or var statements. They are “declared” in a class using access modifiers (e.g., protected $myVar).

If you’re familiar with PHP, the following is pretty simple to follow, and if you’re not, it still should make some sense given the above clues to PHP’s unique features.

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

<?php
abstract class AbClass
{
     public $keyProperty;
 
    // Abstract methods need elaboration in implementation
 
    abstract protected function abFunction();
 
    // All subclasses inherit this method
 
 	public function keyMethod()
       {
        	print $this->abFunction();
		print $this->keyProperty;
    	}
}
 
class ConClass extends AbClass
{
    	protected function abFunction()
	{
        	return "PHP: Detail of abstract method." . "<br />";
    	}
}
 
$keyInstance = new ConClass();
$keyInstance->keyProperty="Key Property: Value of property from abstract class.";
echo $keyInstance->keyMethod();
?>

That little bit of code produces the following:

PHP: Detail of abstract method.
Key Property: Value of property from abstract class.

In ActionScript 3.0, the client would have instantiated the same operations as:

var keyInstance:AbClass =new ConClass();

That’s what it means to program to an interface, and the Gang of Four could not have put it any clearer:

Don’t declare variables to be instances of particular concrete classes. Instead, commit only to an interface defined by an abstract class. You will find this to be a common theme of the design patterns in this book.

So how does one go about creating good PHP that minds its manners as far as OOP principles and design patterns are concerned? In an excerpt from Matt Zandstra’s book, PHP Objects, Patterns, and Practice (Second Edition) I saw the following intriguing kind of code in the context of a Strategy Design Pattern. (Below, I’ve just included a small part and have changed the names to reflect the Strategy pattern structure.)

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

<?php
abstract class Context
{
	private $propertyA;
	private $strategyProp;
 
	function __construct($propertyA, Strategy $strategy)
	{
		$this->propertyA =$propertyA;
		$this->strategyProp = $strategy;
	}
 
	function methodA()
	{
		return $this->strategyProp->methodA($this);
	}
}
?>

In the __construct() function, you can see the parameter pair, Strategy $strategy. Now if you’re a Java or C# programmer, you’ll see that as a typed parameter. (It would be strategy:Strategy in ActionScript 3.0.) However, it turns out to be a way of forming an aggregate relationship between the Context and Strategy classes in a Strategy Design Pattern. (Context delegates to Strategy.) That’s exactly what’s supposed to happen in a Strategy design. However, I’m still not sure what Strategy actually does in the parameter list. Further, if it acts like a typing statement, could it be used to type instances to interfaces? I don’t know, but it’s interesting, and if any of you OOP PHP folks out there know the answer, let us know.

From a Detour to a Mystery

This post started out as a little discussion about building the ActionScript 3.0 Design Pattern at Work survey and trying to be faithful to all of the principles and patterns we’ve discussed in ActionScript 3.0. It led to some mysteries about PHP and OOP, which I find endlessly fascinating. What better challenge could there be than working out design patterns where it appears to be impossible to follow the most fundamental principle of design pattern development—program to an interface, not an implementation.

One possible answer lies in the O’Reilly book, PHP Design Patterns by Stephan Schmidt. When I went to look for it, it was nowhere to be found! It wasn’t on the O’Reilly list or Amazon.com or anywhere. Since I’m one to panic at the drop of a hat, I assumed it has been abducted by aliens, but no. It’s written in German and can be found on the German version of Amazon .com. That’s the end of a promising mystery. Let’s hope it’s translated into English, Spanish, Portuguese and French for us New World types!