ActionScript 3.0 Design Patterns

Note: This is one of those posts that begs for reader comments. PHP is a much-loved language of mine, but I just don’t do the kind of applications that require PHP often. As a result, it stays on the shelf until I need it. So, while very familiar with PHP, I do not claim a high level expertise in it. However, judging from the online PHP discussions and PHP publications, lots of developers are well versed in the language. So, for you PHP’ers out there, your comments are welcomed. (Likewise if you’re not familiar with PHP, feel free to comment as well.)

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!

No related posts.