The ICommand Interface

interface ICommand
{
    /**
     * Run a command
     * @param string $command_type
     * @param args $args
     */
    public function onCommandCall($command_type, $args);
}

This simple interface provides a method for executing a call to initiate a bit of functionality. Along with the classes that execute the functionality, you’ll need a class to handle the chain. We’ll provide this class with another interface requiring the use of a method to add chains and execute commands:

interface ICommandBuilder
{
	/**
	 * Run a command
	 *
	 * @param string $command_type
	 * @param mixed $args
	 */
	public function runCommand($command_type, $args);
 
	/**
	 * Add a new command class
	 *
	 * @param mixed $commanding_class
	 */
	public function addCommand($commanding_class);
}

The two methods here are used for executing commands and adding new command classes. Let’s build the chain-of-command class.

class ChainBuilder implements ICommandBuilder
{
 
	private $_commands=array();
 
	public function runCommand($command_type, $args)
	{
		if (count($this->_commands) > 0)
		{
			foreach ($this->_commands as $class)
			{
				if ($class->onCommandCall($command_type, $args))
				{
					return;
				}
			}
		}
	}
 
	public function addCommand($commanding_class)
	{
		$this->_commands[] = $commanding_class;
		return $this;
	}
}

The class above provides a mechanism for chaining your requests. You add the necessary commands to execute, then pass requests to runCommand, which will loop through all of the commands until one successfully completes the action, or it exhausts all commands. Here you could add interface checks and throw the necessary exceptions for commands not found, etc.

Let’s add a couple of command implementations: email and stream.

class EmailCommand implements ICommand
{
	public function onCommandCall($command, $args)
	{
		if ($command == 'email')
		{
			// send an email with $args
			return true;
		}
		return false;
	}
}
 
class StreamCommand implements ICommand
{
	public function onCommandCall($command, $args)
	{
		if ($command == 'writeStream')
		{
			// Write the stream
			return true;
		}
		return false;
	}
}

These commands email a user and write to a stream. Now let’s use them!

$command = new ChainBuilder();
$command->addCommand(new StreamCommand())->addCommand(new EmailCommand());
$command->runCommand('email',array('email'=>'me@you.com'));
$command->runCommand('writeStream',array('content'=>'Hi, stream!'));

Conclusion

At first glance, the chain-of-command pattern may look like overhead. But on a large code base, this code be useful when making a lot of modifications, etc.

The Observer

<?php
interface IObserver
{
	/**
	 * Method called on event change
	 *
	 * @param mixed $sender
	 * @param mixed $args
	 */
	public function onChange($sender, $args);
}
?>

As you can see from above, the observer implements a single method called onChange. This method is executed when the observable class changes. The first parameter is typically the instance of the class changing and the second arguments relative to the change. Now let’s look at the IObservable interface:

The Observable Object

<?php
interface IObserverable
{
	/**
	 * Add an observer
	 *
	 * @param mixed $obj
	 */
	public function addObserver($obj);
}
?>

The observable class provides a method for one or more observers to be notified. The observable class needs to maintain a list of these observers and notify them when necessary. A common usage of this is a logging mechanism that needs to be notified when data is created, updated and deleted.

<?php
 
class UserLogging implements IObserver
{
 
	public function onChange($sender, $args)
	{
		// Log the changes (we echo here)
		echo 'The class is '.get_class($sender).' and the arguments are '.print_r($args,1);
	}
}
 
class User implements IObserverable
{
	private $_observers=array();
 
	private function notifyObservers($args)
	{
		for ($i=0, $count=count($this->_observers);
			 $i < $count; $i++)
		{
			$this->_observers[$i]->onChange($this, $args);
		}
	}
 
	public function deleteUser($id)
	{
		$db->deleteUser($id);
		$this->notifyObservers(array('user_id'=>$id));
	}
 
	public function addObserver($obj)
	{
		// Add logic for interface implementation check here if you want.
		$this->_observers[] = $obj;
	}
}
 
$user = new User();
$user->addObserver(new UserLogging());
$user->deleteUser(55);
?>

Not only does this provide you some pseudo event access, but this is a much cleaner, maintainable implementation of observing a particular object.

Conclusion

I hope you find ways at work to implement this use pattern. We more often than not get caught up with getting code written (it comes with the territory) and lose sight of these power and proven designs to get the job done. I’m certainly just as much to blame as the next developer! Hope this helps!

PHP provides two interfaces that already define what you should include in an iterator pattern: Iterator and Countable. Below are their definitions:

Iterator Interface

<?php
interface Iterator implements Traversable
{
    public mixed current();
    public scalar key();
    public void next();
    public void rewind();
    public bool valid();
}
?>

Countable Interface

<?php
interface Countable
{
    public int count();
}
?>

You can already iterate over class properties using the foreach() loop, so the Iterator and Countable interfaces are domain specific — meaning the iteration logic is specific to the functionality of the class.

As an example, let’s assume we have a domain model that manages users (CRUD). We have an additional class that acts as a structure (you don’t have to do this, but it’s easier to read in a blog) for each individual user. You also have a method that retrieves an arbitrary number of users, assigns each to a User class (acting as a struct), and gives back an array. While this is certainly doable, the iterator pattern defines an easier way to process the data.

Example Before Iterator Pattern

<?php
 
class User
{
	public $email;
	public $address;
	public $city;
	public $state;
	public $zip;
}
 
class User_Management
{
	/**
	 * List of users
	 */
	private $users=array();
 
	public function getUserByID($id)
	{
		// go get a user and assign it an instance of User
	}
 
	public function getAllUsers()
	{
		// go get all users, assign each to User class, and add to the self::users array
	}
 
}
 
?>

The above example is pretty typical for domain models without the use of iterator. Adding the iterator, we provide an interface to bi-directionally traverse, get key information and count records.

With the Iterator Pattern Implemented

<?php
 
class User
{
	public $email;
	public $address;
	public $city;
	public $state;
	public $zip;
}
 
class User_Management implements Iterator, Countable
{
	/**
	 * List of users
	 */
	private $users=array();
 
	/**
	 * Position of the iterator
	 */
	private $position=0;
 
	/**
	 * Retrieve the current record
	 */
	public function current()
	{
		return $this->users[$this->position];
	}
 
	/**
	 * Return the current key index
	 */
	public function key()
	{
		return $this->position;
	}
 
	/**
	 * Increment the iterator index
	 */
	public function next()
	{
		++$this->position;
	}
 
	/**
	 * Reset the position
	 */
	public function rewind()
	{
		$this->position = 0;
	}
 
	public function getUserByID($id)
	{
		// go get a user and assign it an instance of User
	}
 
	/**
	 * Validate whether a record at current
	 * position exists
	 */
	public function valid()
	{
		return (isset($this->users[$this->position]));
	}
 
	/**
	 * Return the total number of users
	 */
	public function count()
	{
		return count($this->users);
	}
 
	public function getAllUsers()
	{
		// go get all users, assign each to User class, and add to the self::users array
	}
 
}
 
?>

The domain model now implements Countable and Iterator. The below example shows a couple of uses for this:

<?php
 
$iterator = new User_Management();
foreach ($iterator as $index => $value)
{
	// The $index will contain the current key
	// while the $value will contain the user
	// at the current position
	echo $value->address;
}
// Rewind the iterator
$iterator->rewind();
 
while ($iterator->valid())
{
	$value = $iterator->current();
	echo $value->address;
	$iterator->next();
}
 
// Rewind the iterator
$iterator->rewind();
 
for ($iterator->key(); $iterator->valid(); $iterator->next())
{
	$value = $iterator->current();
	echo $value->address;
}
 
?>

Conclusion
This is a much cleaner, easier approach to iterating over objects. I hope you find this usable in your domain models!

For example, let’s assume you have a relatively small system that contains a class called Users. This class reads user data from a small file located on disk. Your system booms, and you need to move to a RDBMS (Relational Database Management System). Because of this, your methods in the class, data source and other items change, breaking the code that is utilizing the Users class. This is where the factory pattern comes in.

The factory pattern’s purpose is to contain methods that create objects for you. Instead of directly instantiating the Users class, you request an instance from a factory class (we’ll call it UsersFactory), and call a static method (we’ll call it getInstance).

Example

<?php
class Users
{
	private $_userId;
	public function getUserById()
	{
		// go get a user
	}
 
	public function __construct($id)
	{
		$this->_userId = $id;
	}
}
 
class UsersFactory
{
	public static function getInstance($id)
	{
		return new Users($id);
	}
}
 
$user = UsersFactory::getInstance($id);
?>

The example above demonstrates how a factory method would work. Now, let’s add in that new class that gets the users from the database. Let’s assume you have 25 other scripts that use the existing class. You can create the new Users_From_DB class and create a static method to reference that as well.

<?php
 
class Users
{
	private $_userId;
	public function getUserById()
	{
		// go get a user
	}
 
	public function __construct($id)
	{
		$this->_userId = $id;
	}
}
 
class Users_From_DB
{
	// same class only from db
}
 
class UsersFactory
{
	public static function getInstance($id)
	{
		return new Users($id);
	}
 
	public static function getUsersFromDB($id)
	{
		return new Users_From_DB($id);
	}
}
?>

This allows you to maintain a loose coupling with a class that could create major problems in the event it goes through major changes.

Conclusion

I have seen where some use the factory pattern as a singleton. They look similar but serve two very different purposes. Take the code below:

<?php
 
class Users_Model
{
	public function getUserById($id)
	{
		// do something
	}
}
 
class Model
{
	private static $instances=array();
 
	public static function factory($model_name)
	{
		if (array_key_exists($model_name, self::$instances))
		{
			return self::$instances[$model_name];
		}
		return self::$instances[$model_name] = new $model_name();
	}
}
 
$model = Model::factory('Users_Model');
$model2 = Model::factory('Users_Model');
?>

While the case could be made that it is acting as a factory pattern, it is being used more as a singleton, maintaining a single instance of a class.

The factory pattern does a really good job, and like the singleton, it serves a very specific purpose.

The singleton pattern is defined as a design pattern that is used to restrict instantiation of a class to one object (or limit number of instances). This is a pretty straight forward concept and works well with many other OOP techniques including the factory pattern. The easiest implementation is to create a public static method within that class that instantiates a new instance.

Example

<?php
class DB_Connection
{
	private $_con = null;
 
    public static function getInstance()
    {
        static $instance=null;
        if ($instance === null)
            $instance = new DB_Connection();
        return $instance;
    }
 
    public function query($sql)
    {
    	// DO SOME CODE TO RUN A QUERY HERE
    }
 
    public function __destruct()
    {
    	$this->_con->close();
    }
 
    private function __construct()
    {
    	$this->_con = new DB::connect('connection_string');
    }
 
}
?>

You’re probably wondering why the class constructor is private. This seems odd as it’s impossible to create an object from outside the class, right? That’s the point. If we don’t limit the class instantiation, the singleton pattern is useless. The method getInstance() can create an object as it’s a member of that class.

How does the static method work?

The static method getInstance() declares a static variable called instance ($instance). The first time this method is called, the $instance variable’s value is null. We then check if the value is null — if it is, we create a new instance of DB_Connection — if it is not, we return the current instance.

Static variables work by declaring the static keyword, then continuing on with the normal variable initialization. The variable will maintain it’s assigned value (whether changed or not) throughout the life of the script.

The second time the getInstance() is called, the $instance variable contains the instance of DB_Connection, and we will return that value. Regardless of how many instances are created of this class, only one object is initialized.

Conclusion

As you can see, the singleton pattern certainly has it’s uses, albeit specific. Keeping the OOP design patterns in mind makes for a cleaner, easier to maintain code base for future developers picking up your projects.

One of the purposes object-oriented programming is to remove ambiguous development and data access items. This basically means identifying common functionality and creating the most reusable framework possible, typically in the form of classes. When creating this functionality, you will begin to have issues with naming conventions and narrowing down functionality even further. To resolve this scoping issue, namespaces allow you to contain those bits of code even more.

UPDATE

Since the writing of this article, PHP has changed the namespace separator to a new character. Please view my update to this article.

Getting Your Environment Setup

Before going any further, you will need to download a release of PHP greater than or equal to 5.3. Since 5.3 is not currently production ready, you can download one of the development releases at snaps.php.net. Once you have that installed, you can use the examples described in this article.

Should I Use Namespaces?

That is a question that can cause controversy among developers. Namespaces are a solution for grouping large sets of libraries and common functionality. The keyword being “large“. You need to be realistic about this. While not definitive, here are some good signs that namespaces are right for you:

1. Your application is not on shared hosting.
2. You have so many libraries, or your framework requires less work by adding class paths to the include_path php.ini directive.
3. More than one developer is working on the application (debatable)
4. You have an existing MVC framework (Code Igniter, Symfony, Zend Framework) that your application is developed on.

Namespaces really can be handy, but they can also cause confusion. Just as you group methods and properties in a class for common, relational functionality, you may group classes and functions even further. However, there are some rules that you must follow.

Now for the Rules

Here are the rules from php.net:

1. All qualified names are translated during compilation according to current import rules. In example, if the namespace A::B::C is imported, a call to C::D::e() is translated to A::B::C::D::e().
2. Unqualified class names are translated during compilation according to current import rules (full name substituted for short imported name). In example, if the namespace A::B::C is imported, new C() is translated to new A::B::C().
3. Inside namespace, calls to unqualified functions that are defined in the current namespace (and are known at the time the call is parsed) are interpreted as calls to these namespace functions, at compile time.
4. Inside namespace (say A::B), calls to unqualified functions that are not defined in current namespace are resolved at run-time. Here is how a call to function foo() is resolved:
   1. It looks for a function from the current namespace: A::B::foo().
   2. It tries to find and call the internal function foo().

   To call a user defined function in the global namespace, ::foo() has to be used.

5. Inside namespace (say A::B), calls to unqualified class names are resolved at run-time. Here is how a call to new C() is resolved:
   1. It looks for a class from the current namespace: A::B::C.
   2. It tries to find and call the internal class C.
   3. It attemts to autoload A::B::C.

   To reference a user defined class in the global namespace, new ::C() has to be used.

6. Calls to qualified functions are resolved at run-time. Here is how a call to A::B::foo() is resolved:
   1. It looks for a function foo() in the namespace A::B.
   2. It looks for a class A::B and call its static method foo(). It will autoload the class if necessary.
7. Qualified class names are resolved in compile-time as class from corresponding namespace. For example, new A::B::C() refers to class C from namespace >A::B.

Okay, so How Do I Use Them?

It seems that PHP will be going with a similar namespace setup as C++. In order to declare a namespace, you will use the “namespace” keyword.

<?php
namespace MyNamespace;
 
class Test {
    public function hello() {
        echo 'Hello';
    }
}
?>

The declaration above simply states that all elements contained in this script will be referenced with the “MyNamespace” namespace. You will need to place the “namespace” declaration at the top of the script.

In order to use a portion of functionality within this script, we will use the Scope Resolution Operator and instantiate the “Test” class.

<?php
// Requiring the namespace file is a good indication that you don't need to use namespaces, but this is only an example!
require('the_file_above.php');
$test = new MyNamespace::Test();
$test->hello();
// Prints 'hello'
?>

Pretty nifty, huh? Okay, so let’s get a little deeper into this. What if you have a complicated set of namespaces that are three or four levels deep? Is this a viable solution?

<?php
$object = new Level1::Level2::Level3::SomeClass();
$object->doSomething();
 
$object2 = new Level1::Level2::Level3::AnotherClass();
$object2->imTiredOfTyping();
?>

In case you’re wondering, the answer is NO. Instead, we can alias a namespace to save some keystrokes and future arthritis pains:

<?php
use Level1::Level2::Level3 as SomeAlias;
 
$object = new SomeAlias::SomeClass();
$object2 = new SomeAlias::AnotherClass();
?>

That saved some time! Now, how do we get that many levels of namespaces and why? Well, the more complicated your framework and libraries become, the more creative naming and depth of namespaces become. For instance, let’s consider a namespace that handles database actions. You may have a MySQL, Postgres, and MS SQL set of drivers. You could setup your namespace levels like this:

• Database
• Mysql
• ActiveRecord
• Pgsql
• ActiveRecord
• Mssql
• ActiveRecord

In this example, albeit not the best, your namespaces could be setup in a relational manner:

Database::Mysql::ActiveRecord;
Database::Pgsql::ActiveRecord;
Database::Mssql::ActiveRecord;

Within the ActiveRecord namespace, you could have a class that handles common database transactions:

<?php
namespace Database::Mysql::ActiveRecord;
 
class Manager  {
    public function select($sql) {
        // do a select
     }
 
    public function update($table,$params) {
        // do an update
    }
}
?>

You could then have a directory outside of the web root called “database” which contains each of these DB namespaces, and add that to your INI “include_path” directive. This makes a large system a little better organized and maintainable. Just remember, namespaces add another layer of complexity to your codebase, so make sure your organization creates standards of developing namespaces.

You can also alias a class within a namespace for use:

<?php
use Database::Mysql::ActiveRecord::Manager as RecordManager;
$manager = new RecordManager();
?>

This scenario is handy if you find yourself instantiating a class multiple times. Declare the use of the namespace all the way to the class level, alias the class, then use it as you would as a normal instantiation.

Global Space

You can also redeclare PHP functionality that is available in the global space. Normally you can’t redeclare a function name without producing a fatal error. In the case of namespaces, it is possible!

Let’s say you want to recreate the function print_r. You might want to add a check to see if the script running is web or CLI (Command Line Interface). You can do so by prefixing the PHP function with the Scope Resolution Operator:

<?php
namespace String;
 
function print_r($string) {
    // Assume CLI
    if (isset($argv)) {
        ::print_r($string);
    } else {
        // Add <pre> tags for better output to a browser
        printf('<pre>%s< /pre>', ::print_r($string,1));
    }
}
?>

You could then call this function:

<?php
require('String.php');
String::print_r('Test text');
?>

This allows you to “redeclare” print_r.

Conclusion

As I took a glance at the upcoming namespace functionality in PHP 5.3, I was intrigued, but a little disappointed. I was really hoping that PHP would implement similar functionality to C#, but PHP is a very well-developed language that is constantly being improved, and the OOP implementation between versions 4 and 5 can account for that. I have high hopes that PHP will increase the functionality of namespaces, and satisfy users that have been using them for years with other tools. There is no doubt in my mind that PHP is heading in the right direction!