A Php Mysql Ajax Developer

What is Memcache

2008-04-27T13:20:00.011+05:30

Introduction

Memcache module provides handy procedural and object oriented interface to memcached, highly effective caching daemon, which was especially designed to decrease database load in dynamic web applications.

Memcached is a high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load.

The Memcache module also provides a session handler (memcache).

More information about memcached can be found at » http://www.danga.com/memcached/.

Lazy Initialization Pattern

2008-04-24T11:22:00.000+05:30

Lazy initialization is the tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed.

In a software design pattern view, lazy initialization is often used together with a factory method pattern. This combines three ideas:

using a factory method to get instances of a class (factory method pattern)
storing the instances in a map, so you get the same instance the next time you ask for an instance with same parameter (compare with a singleton pattern)
using lazy initialization to instantiate the object the first time it is requested (lazy initialization pattern).

A Simple PHP Example

php

class User
{
protected $_id;

public function getId()
{
   return $this->_id;
}
}

class Post
{
protected $_userId;

protected $_text;

/**
*
* @var User
*/
protected $_user;


public function setUser(User $user)
{
   $this->_userId = $user->getId();
   $this->_user = $user;
}

public function getUser()
{
   if (!$this->_user) {
       $this->_user = new User($this->_userId);
   }
   return $this->_user;
}

public function setText($text)
{
   $this->_text = $text;
}

public function getText()
{
   return $this->_text;
}
}

A PHP 5 Example

php

class View
{
protected $_values = array();

public function set($name, $value)
{
   $this->_values[$name] = $value;
}

public function render($file)
{
   extract($this->_values);
   ob_start();
   include($file);
   return ob_get_clean();
}
}

class Page
{
/**
* View object.
*
* @var View
*/
protected $_view;

public function __construct()
{
   // remove attribute to use the __get magic method in first access
   unset($this->_view);
}

public function __get($name)
{
   if ($name == '_view') {
       // load view object
       $this->_view = new View();
       return $this->_view;
   }
}

public function actionIndex()
{
   $this->_view->set('title', 'Lazy Initialization');
   print $this->_view->render('lazy.tpl');
}
}

Transfer Object Pattern

2008-04-24T11:14:00.000+05:30

Introduction

The intuitive naming of Patterns gives a clue as to the meaning of a Transfer Object. In short a Transfer Object bundles data into a single, easy to transport object. The Transfer Object can sometimes be referred to as the Data Transfer Object (as in POEAA). Both names refer to the same Design Pattern.

There are a number of reasons why a Transfer Object is useful. By grouping related sets of data in a single object, it reduces the complexity of passing such data into methods by removing long parameter lists. Long parameter lists are often termed a "code smell" since they can be confusing and parameter order must be maintained even if a value is not used. As a return value from a method, a Transfer Object also enables multiple values be returned.

Of course this can be easily accomplished in PHP by an array. While a Transfer Object may resemble an array, it has other features that ultimately make it more useful:

A Transfer Object has a class type which can help enforce an interface by using PHP5's Type Hinting.
It's preset properties will always be available (with default values). One can even prevent the setting of new public properties.
It is possible to perform additional actions in a Transfer Object upon setting a new value via PHP5's Magic Methods.

Definition

Definition: The Transfer Object allows the encapsulation of multiple known values in a single object that supports basic data storage and retrieval functionality.

Implementation for PHP5

Implementing a Transfer Object is quite simple. A distinction should however be made between a Transfer Object and the very similar Value Object. The values in a Transfer Object are not immutable, i.e. they can be changed via a public interface (getters and setters) or by defining the Transfer Object's properties as public or using Magic Methods to simulate public properties in the interface. Often the two Pattern titles are used interchangeably although there are differences in their respective goals.

An example of a Transfer Object might be an object which stores the data associated with a row in a database table. Rather than passing each database value individually to other objects' methods, one need only pass the representative Transfer Object. This simplifies operations quite a bit and removes a lot of complexity from a class interface if used wisely.

Moreover, since a Transfer Object has a specific class type. An accepting method can restrict a parameter to only accept the expected Transfer Object by using Type Hinting.

A simple PHP5 Transfer Object:

php

class User_Row {

  public $user_name = '';
  public $user_password = '';
  public $user_email = '';
  public $user_url = '';

  public function __construct($name='', $password='', $email='', $url='') {
      $this->user_name = $name;
      $this->user_password = $password;
      $this->user_email = $email;
      $this->user_url = $url;
  }

}

Note that the properties are defined as public. For this Transfer Object, the client code can use the properties directly without accessors. Since a Transfer Object by definition is not designed to hold arbirary properties (created by client code), the Registry Pattern is more suited for such a purpose or one can even fall back on an array. While a Registry is agnostic to its contents, a Transfer Object's property names (or alternatively the matching setters/getters) form part of its testable interface.

A Unit Test (using SimpleTest) for the above simple Transfer Object would contain:

php

class TestUserRowSimple extends UnitTestCase {

  public function testConstructor() {
      $row = new User_Row('name', 'password', 'email', 'website');
      $this->assertEqual($row->user_name, 'name');
      $this->assertEqual($row->user_password, 'password');
      $this->assertEqual($row->user_email, 'email');
      $this->assertEqual($row->user_url, 'website');
  }

  public function testPublicProperties() {
      $row = new User_Row;
      $row->user_name = 'name';
      $row->user_password = 'password';
      $row->user_email = 'email';
      $row->user_url = 'website';
      $this->assertEqual($row->user_name, 'name');
      $this->assertEqual($row->user_password, 'password');
      $this->assertEqual($row->user_email, 'email');
      $this->assertEqual($row->user_url, 'website');
  }

}

It's worth noting that the most common alternative to a Transfer Object is a simple array. An array and a simple Transfer Object share similar characteristics. A Transfer Object however has a class type and will always contain specific properties (optionally with default values). Additionally a Transfer Object can perform it's own private internal operations on incoming and outgoing data by using the PHP5 Magic Methods: __set() and __call() to overload the public properties.

Let's consider our previous User Row example. As the User Row Transfer object is passed around our application and other classes may alter the original data. This changed data will need to be stored to the database. To prevent unnecessary SQL update operations, we would like if the Transfer Object could inform the application whether it's data has been changed (i.e. dirty) or unchanged (i.e. clean).

For the example below we'll make use of PHP5's Magic Methods in order to control the value of an additional private property - isDirty. Other objects will be able to retrieve the value of isDirty by calling the isDirty() method.

php

class User_Row {

  private $data = array(
      'user_name' => '',
      'user_password' => '',
      'user_email' => '',
      'user_url' => ''
  );

  private $isDirty = false;

  public function __construct($name='', $password='', $email='', $url='') {
      $this->data['user_name'] = $name;
      $this->data['user_password'] = $password;
      $this->data['user_email'] = $email;
      $this->data['user_url'] = $url;
  }

  public function __get($name){
      if (isset($this->data[$name]))
      {
          return $this->data[$name];
      }
  }

  public function __set($name, $value){
      if (isset($this->data[$name]))
      {
          $this->data[$name] = $value;
          if($this->isDirty === false)  {
              $this->isDirty = true;
          }
      }
  }

  public function __isset($name) {
      return isset($this->data[$name]);
  }

  public function __unset($name) {
      unset($this->data[$name]);
  }

  public function isDirty() {
      return $this->isDirty;
  }

}

The differences from our simple prior example are not all that complex assuming you are familiar with PHP5's overloading[1] magic methods. The use of the Magic Methods sets up access to private member properties (the private $data array) while upholding the interface that properties are publicly accessible.

Overloading with magic methods lets us use the class in the same way as the first example only this time the Transfer Object can check whether it's default values have changed by setting the value of the isDirty property to TRUE. There are no public properties since magic functions cannot overload a property which is already defined - hence they are moved to a private array. As a last step we add a public getter method to retrieve the isDirty value.

The use of magic methods which rely solely on a defined private array of possible values also has an additional effect: it prevents the setting of any new public properties by client code. In effect the magic methods version is limited to the defined properties - no new ones can be set.

In both cases, the classes can be used in the following way.

php

require 'User_Row.php';

$row = new User_Row('Padraic', 'mypassword', 'myemail', 'mywebsite');

// test output

echo $row->user_name, PHP_EOL;
echo $row->user_password, PHP_EOL;
echo $row->user_email, PHP_EOL;
echo $row->user_url, PHP_EOL;

Output:

Padraic mypassword myemail mywebsite

As with our simple Transfer Object, we can verify that the complex version follows an identical interface as the simple version by writing a Unit Test to verify the expected behaviour of the class. The Unit Test is identical to the last version, except that we additionally ensure the isDirty property value is set to TRUE when a value is changed from the defaults (set via the constructor when a User_Row object is instantiated.

php

class TestUserRowComplex extends UnitTestCase {

  public function testConstructor() {
      $row = new User_Row('name', 'password', 'email', 'website');
      $this->assertEqual($row->user_name, 'name');
      $this->assertEqual($row->user_password, 'password');
      $this->assertEqual($row->user_email, 'email');
      $this->assertEqual($row->user_url, 'website');
  }

  // public properties (per the established interface) are now
  // handled by PHP's magic __set() and __call() methods
  // But it still adhere's to the same interface!

  public function testPublicProperties() {
      $row = new User_Row;
      $row->user_name = 'name';
      $row->user_password = 'password';
      $row->user_email = 'email';
      $row->user_url = 'website';
      $this->assertEqual($row->user_name, 'name');
      $this->assertEqual($row->user_password, 'password');
      $this->assertEqual($row->user_email, 'email');
      $this->assertEqual($row->user_url, 'website');
  }

  // This version has additional behaviour - the isDirty property
  // is given a TRUE value when the defaults (passed in constructor)
  // are changed.

  public function testIsDirty() {
      $row = new User_Row('myname');
      $row->user_name = 'mynewname';
      $this->assertTrue( $row->isDirty() );
  }

  // The __set() method is also designed to only set values whose
  // property names are defined in the private $data array. This
  // prevents client code adding new arbitrary properties. Attempts
  // to add new public properties are ignored.

  public function testNoNewPublicProperties () {
      $row = new User_Row;
      $row->new_property = 1;
      $this->assertNull($row->new_property);
  }

}

As we previously noted. A Transfer Object has a class type - an array has no specific type except the generic "array" (from PHP 5.1). This difference is one further advantage of using this pattern instead of an array. If you take the following client code, any attempt to pass a parameter which is not an object of the type User_Row to the constructor will result in a fatal error. This safety net feature ensures client code adheres to this class's interface and is not capable of passing other object types or arrays. For example, our User_Row_Printer class below only knows how to work with User_Row objects - giving it any other object might result in unexpected output or a fatal error.

php

class User_Row_Printer {

  private $user_row = null;

  public function __construct(User_Row $user_row) {
      $this->user_row = $user_row;
  }

  public function print() {
      echo $this->user_row->user_name, PHP_EOL;
      echo $this->user_row->user_password, PHP_EOL;
      echo $this->user_row->user_email, PHP_EOL;
      echo $this->user_row->user_url, PHP_EOL;
  }

}

[edit]

Implementation for PHP4

Implementing a PHP4 Transfer Object is not as effective as in PHP5. The lack of property visibility keywords (private, protected and public) mean that property access cannot be restricted. This rules out effective getters and setters which might replace the PHP5 use of the magic methods __get() and __set(). Getters and setters can be implemented, but without access keywords the client is free to ignore them and access the object properties directly.

Still, the basic structure remains the same and type hinting (if desireable) can be implemented within any method by making an is_a() check against the lowercased class type of the relevant Transfer Object being passed as a parameter to the method.

A simple Transfer Object example for PHP4:

php

class User_Row {

  var $user_name = '';
  var $user_password = '';
  var $user_email = '';
  var $user_url = '';

  function User_Row($name='', $password='', $email='', $url='') {
      $this->user_name = $name;
      $this->user_password = $password;
      $this->user_email = $email;
      $this->user_url = $url;
  }

}

Unit Testing of the PHP4 version is largely similar to the PHP5 Unit Tests (minus the PHP5 syntax differences).

[edit]

Conclusion

The Transfer Object is a simple Design Pattern. At first glance it can easily be mistaken for a glorified array but there are a number of important differences. Unlike an array, a Transfer Object has a specific type which allows a class's method be restricted to only accepting a specific Transfer Object through Type Hinting. While an array can have any number of additional fields appended, a Transfer Object can have a fixed number of properties enforced (see PHP5 complex example code). As a result, Transfer Objects of the same type can always be handled in the exact same way. Another difference is that a Transfer Object can perform its own internal operations when values are set. The PHP5 examples above illustrate how a User_Row object can track whether it's default values have changed since the object was created thereby allowing client code (perhaps a Data Access class) tell when the database row the Transfer Object represents requires updating.

On a par with an array, a Transfer Object by bundling multiple values in a single entity can help alleviate the long parameter list "code smell" when refactoring and enable methods to return multiple values encapsulated in an object. This is not its primary purpose, but the resemblance to a Parameter Object is close.

Decorator Pattern

2008-04-23T22:39:00.000+05:30

Introduction

Note: This is a draft article dated 14 September 2006. The supplied code has not been tested.

Altering the behaviour of objects is a tricky business. In many cases you do not wish to alter the original object but rather tack on additional or modified behaviours. The easiest way to achieve this is using inheritance. Creating a series of subclasses allows a programmer to add additional methods and properties or alter those which already exist in the parent class. Unfortunately, as other Design Patterns often point out, inheritance can be a path full of pitfalls and traps for the unwary. The more layers exist in a class hierarchy, the more cumbersome and difficult to manage the whole structure becomes.

If we decide to set a goal of maintaining the original class as is and of disallowing any further inheritance, we immediately gain some measure of control. By preventing further inheritance we have a smaller discrete unit perfect for reuse in other projects minus the specific modifications current circumstances might require. To extend the original class and add new or modified behaviour to it we can use the Decorator Pattern.

The Decorator Pattern creates a separate class family which adds extended behaviour to an existing class while leaving the existing class unchanged. As the class is ported for reuse, we can transparently add new Decorators specific to each new application as we see fit. Additionally, since the Decorator classes are in a separate hierarchy they have a variable type which is distinct from the original class, i.e. we can tell if a class is a Decorator.

Of course the Decorator Pattern is not a silver bullet. Inheritance remains the simplest option and the Decorator Pattern is not suitable for all scenarios. However it remains an extremely useful option and is one of the more popular Design Patterns programmers are intimately familiar with, especially in web application development.

Pattern Definition

Definition: The Decorator Pattern represents the process of creating a new class hierarchy which adds new or modified behaviour to an existing class without modifying the existing class from its original state.

Description of the Problem

Let's introduce an example of a situation which lends itself to improvement through the application of the Design Pattern. During the development of an application we discover a need to store data to a file. For simplicity, the data is a simple string. A generic String_Writer class is ported from a pre-existing project. The class simply accepts a string and writes it to a specified file, storing the data in a property access by a public getter/setter pair. The class is generic in that it just stores strings. Outputting and additional formatting for display is not handled by the basic class. As a result it is decided to extend the String_Writer class behaviour to add formatting options for output and to add an output method.

Inheritance has been ruled out as an option for a number of reasons. First of all, there can be any number of formatting options. Adding each option to the original String_Writer class through inheritance could become complex, resulting in a class hierarchy many levels deep. Changes to any class high in the hierarchy might require modifying all subsequent child classes for the change in interface or properties in the higher level parent - a time-consuming task.

The Decorator Pattern on the other hand avoids multi-level inheritance.

Implementing the Decorator Pattern in PHP5

The basic String_Writer class is extremely simple:

php

class String_Writer {

   private $path = '';
   private $string = '';

   public function __construct($path) {
       $this->path = $path;
   }

   public function setString($string) {
       $this->string = $string;
   }

   public function getString() {
       return $this->string;
   }

   public function getPath() {
       return $this->path;
   }

   public function store() {
       // we assume one string per line
       if(!file_put_contents($this->path, $this->string . PHP_EOL, FILE_APPEND))
       {
           throw new Exception('Error writing to specified path');
       }
   }
  
}

The String_Writer class should be fairly simple to follow. We instantiate the class passing the path to the relevant log file in the constructor parameter. To store a new string in the file, we call setString(), followed by store(). Each store appends a newline to the data using the PHP_EOL constant to be agreeable for Unix, Mac or Windows systems.

In order to format the stored string for output without resorting to inheritance, we create a new class hierarchy. It's structure will be simple, a parent class and any number of specific child classes. We will call the parent class String_Formatter. The Formatter and its children implement the Decorator Pattern, i.e. they extend the functionality of the existing class, String_Writer, by supplying new formatting and output options. The String_Writer class is left unchanged.

The String_Formatter class is as follows:

php

class String_Formatter {

   private $string = '';

   public function __construct(String_Writer $writer) {
       $this->string = $writer->getString();
   }

   public function getString() {
       return $this->string;
   }

   public function setString($string) {
       $this->string = $string;
   }

   public function output() {
       return $this->string;
   }

}

The String_Formatter class is likewise simple. The additional behaviour is simply the output() method. By default this simply returns the value of the string held by the String_Writer object. No formatting is performed by default.

To make things interesting, we extend our basic String_Formatter class with a selection of child classes which format the output string. Here's three examples: Uppercase, Reverse, and Escape.

php

interface iString_Formatter {

   public function format();

}

class String_Formatter_Uppercase extends String_Formatter implements iString_Formatter {

   private $stringFormatter;

   public function __construct(String_Formatter $stringFormatter) {
       $this->stringFormatter = $stringFormatter;
   }

   public function format() {
       $this->stringFormatter->setString(
           strtoupper($this->stringFormatter->getString())
       );
   }

}

class String_Formatter_Reverse extends String_Formatter implements iString_Formatter {

   private $stringFormatter;

   public function __construct(String_Formatter $stringFormatter) {
       $this->stringFormatter = $stringFormatter;
   }

   public function format() {
       $this->stringFormatter->setString(
           strrev($this->stringFormatter->getString()));
   }

}

class String_Formatter_Escape extends String_Formatter implements iString_Formatter {

   private $stringFormatter;

   public function __construct(String_Formatter $stringFormatter) {
       $this->stringFormatter = $stringFormatter;
   }

   public function format() {
       $this->stringFormatter->setString(
           htmlentities($this->stringFormatter->getString(), ENT_QUOTES, 'UTF-8')
       );
   }

}

Each individual subclass performs a different formatting function. Of course using just one type of formatting is limited. Rather each subclass of String_Formatter accepts other related classes of the same type as arguments to its constructor. By linking all the decorators to each other, it is possible to perform specific formatting by calling each Decorator's formatting method.

An example usage:

php

require('String_Writer.php');
require('String_Formatter.php');
require('iString_Formatter.php');
require('String_Formatter_Uppercase.php');
require('String_Formatter_Reverse.php');
require('String_Formatter_Escape.php');

$string = 'php rof snrettap';
$path = '/tmp/stringlog';

/*
Create a new String_Writer object
*/
$stringWriter = new String_Writer($path);
$stringWriter->setString($string);

/*
Store the string to a file
*/
$stringWriter->store();

/*
Instantiate a String_Formatter object to control output
*/
$stringFormatter = new String_Formatter($stringWriter);

/*
Instantiate specific String_Formatters. Pass in String_Formatter object
as parameter to first Formatter. Pass new Formatter into third, etc.
This chained set of parameters links all the Formatters to the same string.
*/
$stringUppercase = new String_Formatter_Uppercase($stringFormatter);
$stringReverse = new String_Formatter_Reverse($stringUppercase);
$stringEscape = new String_Formatter_Escape($stringReverse);

/*
Perform the formatting, call format() method of each required Formatting option
*/
$stringUppercase->format();
$stringReverse->format();
$stringEscape->format();

/*
Return the results for output
*/
$output = $stringFormatter->output();

/*
Exit the script while printing the resulting formatted string (which is also
stored in our log file in original form)
*/
exit($output); // PATTERNS FOR PHP (reversed, uppercased and escaped!)

Disadvantages

The Decorator Pattern is not suitable for all possible situations. If the number of Decorator options is limited and it does not add significantly to the number of hierarchy levels then inheritance is possibly a better option. In general however, class hierarchies should be fairly shallow. If a hierachy of classes is more than three levels deep then you should consider refactoring some of the additional elements using the Decorator Pattern or certain other Patterns instead. A deep class hierarchy can easily become a morass of dependencies where changes have knock on effects across numerous inheriting classes. Avoiding such maintenance black holes should be a priority.

Conclusion

In this article we have briefly examined a simple implementation of the Decorator Pattern. This pattern is an alternative to persistent subclassing in order to add new or modified behaviour to the ultimate parent class. Rather than using inheritance, one can build a separate class hierarchy of the behaviour required and apply the methods of the new classes to the original class. An essential feature of the Decorator Pattern is that the original class does not require any additional modification in order to apply the Pattern.

Composite Pattern

2008-04-23T22:36:00.000+05:30

A Composite a means of assembling and organising classes such that standalone objects and object collections are members of the same class hierarchy and may be used by client code without distinguishing between them.

Imagine for a moment a book. In a book, you'll find pages, chapters, cover-pages, subsections, prefaces, etc. Of course, we don't slop them all together and call it a book: the book is divided into chapters, which are then further divided into pages. An in-memory representation of a book composite might look like this:

At first blush, it might seem logical to simply claim that a book only contains chapters, chapters only contain sections and sections only contain pages, and have each of the classes code around each of their unique interfaces. But there are common traits around all these elements, for example, they all contain text (or at least their children do). Standardize the interfaces around these common traits, and you've got a composite.

Example

Before we demonstrate the implementation of the pattern, let's look at how client code might utilise it. Let's take the example from our introduction a bit further. After implementing each of the Book, Chapter and Page classes we would expect our client code to utilise all these objects without distinguishing between them.

php

$book = new Book('Patterns For PHP');
$prologue = new Chapter('Prologue');
$chapter1 = new Chapter('Chapter 1: The Strategy Pattern');
$chapter2 = new Chapter('Chapter 2: The Registry Pattern');

// Add pages to all chapters
$prologue->addText( new Page('/home/user/pfp/page_prologue.html') );
$chapter1->addText( new Page('/home/user/pfp/page2_1.html') );
$chapter2->addText( new Page('/home/user/pfp/page3_1.html') );

// Create last page (stand-alone, has no parent chapter)
$lastPage = new Page('/home/user/pfp/page_last.html');

// Fill up the book
$book->addText($prologue);
$book->addText($chapter1);
$book->addText($chapter2);
$book->addText($lastPage);

$display = isset($_GET['c']) ? (int) $_GET['c'] : false;
if ($display !== false && $book->childExists($display_chapter)) {
   // Output only part of the book
   $book_child = $book->getChild($display);
   echo $book_child->output();
} else {
   // Output the book
   echo $book->output();
}

Notice how Book and Chapter both have addText() methods, rather than their own addChapter() and addPage() methods. This allows us to insert the standalone page, something not possible if it was assumed that all the children of a Book were chapters. Furthermore, all the classes in the hierarchy implement output(), allowing us to show the entire book, just one chapter, or even a single page.

Those familiar with the Document Object Model may note striking similarities between our example and the standard use-case of DOM. This is intentional: DOM is an extremely good example of the composite pattern. All elements in an XML document boil down to nodes, and they can be treated uniformly whether they are elements, text, or the document root node.

Implementation

This section is actively under discussion, see Talk:Composite.

Before we can actually start writing the code, there are a few common implementation issues we have to deal with first.

Child management operators

You may have noticed that in the above code, we never executed addText() on a page object. Since it's not a composite, such an operation is not meaningful. However, the whole point about composition is that you can treat components uniformly! Gang of Four boils it down to a trade-off between "safety and transparency". You can:

Define child operations at the very bottom of the class hierarchy, so that even the non-composite objects have it. This lets you treat all objects uniformly, but lets the client do meaningless things like $marble->add($bag). In our case, however, we can implement an interesting fallback behavior: call output() on the passed node and then concatenate that to the existing page contents. This may not always be possible, however, and even when it is, it should be considered poor form.
Define child operations only for Composites. While this means that it's now impossible for the client to add bag to the marble, it also means that the interfaces aren't uniform anymore.

The first possibility might look like this:

php

abstract class BookNode {
   // do nothing by default, we could also throw an exception
   public function addText() {}
   abstract function output();
   // all other standardized functions
}
abstract class BookComposite extends BookNode {
   private $texts = array();
   public function addText() {/* ... */}
   public function output() {/* ... */}
}
class Book extends BookComposite {/* ... */}
class Chapter extends BookComposite {/* ... */}
class Page extends BookNode {
   // we could keep the default behavior of doing nothing,
   // or we could implement the fallback behavior
   public function addText(/* ... */}
}

While the second possibility would look like this:

php

abstract class BookNode {
   abstract function output();
   // all other standardized functions
}
abstract class BookComposite extends BookNode {
   private $texts = array();
   public function addText() {/* ... */}
   public function output() {/* ... */}
}
class Book extends BookComposite {/* ... */}
class Chapter extends BookComposite {/* ... */}
class Page extends BookNode {/* ... */}

Throwing an "Attempt to call undefined function" error when addText is called on Page.

A rich base interface

The previous issue ties into a more general one, that is, how much should we stuff into the parent class? On one hand, anything we put into the base class is uniform across the entire hiearchy and can be used with impunity. On the other hand, it could mean a lot of junk methods that are meaningless for a particlar object in the hierarchy. The advice it to use good judgment and a little creativity for default behavior.

[edit]

Code

So, here's an implementation of the book class mentioned above.

php

abstract class BookNode {
   abstract public function addText() {}
   abstract public function output() {}
   public function __toString() {
       return $this->output();
   }
}
abstract class BookComposite extends BookNode {
   protected $texts;
   public function addText($node) {
       $this->texts[] = $node;
   }
   public function output() {
       $ret = '';
       foreach ($texts as $text) {
           $ret .= $text->output();
       }
       return $ret;
   }
   public getChild($index) {
       if (isset($this->texts[$index])) return $this->texts[$index];
       // if we wanted to be nicer, we could
       // return a BookNodeNotFound class which
       // outputs a nice error message
       throw new Exception('Child doesn\'t exist!');
   }
}
class Book extends BookComposite
{
   protected $title;
   public function __construct($title) {
       $this->title = $title;
   }
   public function output() {
       $ret = "{$this->title}
";
       $ret .= parent::output();
       return $ret;
   }
   function getChapter()
}
class Chapter extends BookComposite
{
   protected $title;
   public function __construct($title) {
       // I know, it's a little duplication. If there
       // are a lot more titled objects added to the
       // hierarchy, you may want to consider
       // a BookTitledComposite abstract class.
       $this->title = $title;
   }
   public function output() {
       $ret = "{$this->title}
";
       $ret .= parent::output();
       return $ret;
   }
}
class Page extends BookNode
{
   protected $contents = '';
   public function __construct($source_file) {
       $this->contents = file_get_contents($source_file);
       // we should check to make sure the source file exists
   }
   public function addText($node) {
       // convenience function
       if ($node instanceof BookNode) {
           $this->contents .= $node->output();
       } else {
           $this->contents .= (string) $node;
       }
   }
   public function output() {
       return $contents;
   }
}

Note that in this example the model and view are mixed together, which is generally considered a no-no. Find out how to seperate the HTML generation from these classes using a Visitor. You may also want to go through the book page by page, that would be implemented with an Iterator.

Strategy Pattern

2008-04-23T22:32:00.000+05:30

In an object oriented application, whenever a new task is identified a programmer's response is usually to create a new class to represent it. Over time however the class may evolve to include numerous sub tasks, each of which adds further complexity to the original class. In some cases, such sub tasks may have many alternatives. An example is a Logger class. It's original task is to write a log message to a file. In time one might expand its capablities to write to numerous targets: File and Database. An additional requirement might allow the message to be formatted in various ways: a simple String, XML, serialised data, or perhaps HTML.

Our class now has one primary task, Logging, and two distinct sub tasks, Formatting and Writing. Each sub-task has many competing implementations. The Strategy Pattern suggests a means of implementating a class structure which allows programmers manage such flexibility easily to allow future growth, while avoiding some common pitfalls met in allowing and supporting such flexibility. Furthermore, the Strategy Pattern demonstrates how composition is often far more powerful than simple sub classing.

Implementing the Strategy Pattern

At its heart, our Logging class desperately wishes to be simple. It accepts a message and writes it somewhere for storage. No matter how we refactor and extend the Logger we should aim at maintaining a simple interface. While in PHP 4 this was largely a matter of programmer discipline, PHP 5 offers the ability to enforce an interface. It's as simple as creating an Interface (something similar to a class) to which all possible concrete Logger classes must adhere.

php

interface iWriter {

  public function write();

}

A lengthy explanation of Interfaces is not required. All classes which implement an Interface must supply a list of methods as defined by the Interface. Failing to do so will generate a fatal error. We named our interface iWriter rather than iLogger, since the latter is a more generic description and may possibly be reused for another class family.

With an interface decided upon, let's revisit the Logger example. Our original Logger class might look similar to:

php

class Logger {

  private $file = null;

  public function __construct($file) {
      $this->file = $file;
  }

  public function write($message) {
      file_put_contents($this->file, array(PHP_EOL, $message), FILE_APPEND);
  }

}

This class is ultra simple. It is instantiated with the location of the file to store log messages to. When Logger::write() is called, it opens the file and appends the $message parameter value to the end of the file (preceded by a new line character). The array of values is automatically concatenated (just as if we used join()) and the FILE_APPEND flag ensures we do not overwrite any existing data in the file.

It's use should be quite obvious.

php

$logger = new Logger('/tmp/mylog');
$logger->write('This is a log message!');

Unfortunately, the requirements for our Logger may prove more complex. As noted in our introduction, the Logger must store messages to either a file or a database. Whichever we use, the simplest solution is to create sub classes of the Logger class. We would call these classes Logger_File and Logger_DB. Their implementation is not important right now.

The difficulty arises when we add a second variable element. Our requirements grow to include various methods of formatting a message before it is stored. This creates a lot of confusion. Sub classing excels at splitting variability between two options in a class into two new and separate classes, i.e. just as we did in considering Logger_File and Logger_DB sub classes to split the storage option into separate classes. Unfortunately, once the number of variances grow beyond one, sub classing produces something ugly. Consider our current sub classes, Logger_File and Logger_DB. If we add various formatting methods, we would need to sub class both of these in turn to support each formatting option. If our formatting options include String, XML and HTML our list of classes would resemble:

Logger_DB_String
Logger_DB_XML
Logger_DB_HTML
Logger_File_String
Logger_File_XML
Logger_File_HTML

We now have six subclasses of Logger.

We can make a few educated observations about this structure before writing so much as a single line of code.

The task of formatting is duplicated for each of the two output options, both DB and File.
Adding a new format would result in needing to add two new sub classes (one for each output option).
Adding a new output would result in adding three new classes (duplicating all formats for the new output).
1-3 above are undesired effects which will make this design very difficult to maintain and extend.

These observations demonstrate a severe weakness of relying solely on sub classing to solve our problems. Each additional option will exponentially increase the number of classes we must add to support it. Adding just a few options would result in DOZENS of new classes, each of which adds to the confusion and duplication of code.

The solution? Well, you read this article's title I hope ;). The Strategy Pattern solves this issue very neatly by using the power of composition to replace the continually increasing depths of an expanding class hierarchy. The Pattern is actually quite simple, and something no few programmers with some experience will readily have suggested the moment we defined the Logger problem. They may never have even heard of the Strategy Pattern and simply stumbled upon the solution themselves.

The Strategy Pattern works by identifying each of those variable sub tasks and isolating them into a new class family. Let's consider the Logger sub class list again. The most variable task is the formatting. There are two output types and its unlikely we need many more. Formatting however is far more open. There could be dozens of ways the person using the Logger might want to format the message. We could in fact add a sprintf format to enable such flexibility without forcing programmers to define loads of custom formats. But this is outside the scope of our simple example.

Since formatting is the most variable and the most likely to see new options, we will cut it out of Logger completely. Formatting could be added to a new Formatter class family. We could create a superclass called Formatter and then subclass it for each formatting method. In our case, each formatting option has no common tasks - in the world of formatting each does its own unique thing. This means we can do away with a common parent class. Since a guiding principle of Design Patterns (and OOP in general) is to "code to an interface, not an implementation" we do however make certain each Formatter follows the same interface. In PHP 5, we can enforce this by defining an Interface.

php

interface iFormatter {

  public function format();

}

With an Interface in place, we can continue creating Formatter classes.

php

class Formatter_String implements iFormatter {

  public function format($message) {
      return $message.PHP_EOL;
  }

}

class Formatter_XML implements iFormatter {

  public function format($message) {
      $timestamp = time();
      // heredoc string syntax
      $xml = <<
              $timestamp
              $message
          
XML_EOL;
      return $xml.PHP_EOL;
  }

}

class Formatter_HTML implements iFormatter {

  public function format($message) {
      $timestamp = time();
      // heredoc string syntax
      $html = <<
          Timestamp: $timestamp
         

          Message: $message
          

HTML_EOL;
      return $html.PHP_EOL;
  }

}

With our Formatter class structure in place, we now consider how to utilise it within our Logger class. Without the formatting options, our Logger class family has shrunk to a far more manageable count of three classes. We have the Logger parent class, and two sub classes, Logger_File and Logger_DB.

The Logger parent class now looks like:

php

abstract class Logger implements iWriter {

  protected $formatter;

  protected function __construct($formatter) {
      if($formatter instanceof iFormatter)
      {
          $this->formatter = $formatter;
      }
      else
      {
          trigger_error('Invalid Formatter!', E_USER_ERROR);
      }
  }

}

class Logger_File extends Logger {

  private $file = null;

  public function __construct($formatter, $file) {
      parent::__construct($formatter);
      $this->file = $file;
  }

  public function write($message) {
      $formatted_message = $this->formatter->format($message);
      file_put_contents($this->file, $formatted_message, FILE_APPEND);
  }

}

class Logger_DB extends Logger {

  // $db in this case is a database connection object from ADOdb Lite
  private $db = null;

  public function __construct($formatter, $db) {
      parent::__construct($formatter);
      $this->db = $db;
  }

  public function write($message) {
      $formatted_message = $this->formatter->format($message);
      $_date = time();
      $_escaped_message = $db->qstr($message);
      $this->db->Execute('INSERT INTO app_log_messages (time, message) VALUES (' . $_date . ',' . $_escaped_message . ')');
  }

}

Whenever we create a new Logger class, we can now pass a Formatter object as a parameter via its constructor. This Formatter object, regardless of its actual type, will always follow the exact same interface. For this reason the Logger can use any Formatter very easily - use its write() method as enforced by the iWriter interface. If you consider the new structure - the Logger and the Formatter class family it uses via composition - there is a marked improvement over the original design which relied solely on sub classing.

Using our new Logger and the Formatter class type we created in applying the Strategy Pattern is as simple as:

php

// log a message in XML format to an XML file

$logger = new Logger_File(new Formatter_XML(), '/tmp/mylog.xml');
$logger->write('I am an XML formatted log message!');

The improvement in design is due to implementing the Strategy Pattern on Logger; divorcing the formatting variability into its own class type and associating the Logger with a Formatter by passing it into Logger as a construction parameter. During the 1990's, the Gang of Four in their "Design Patterns" book offered the following principle. Favour composition over subclassing. The Strategy Pattern demonstrates this principle in action very nicely.

What else can we say about the Strategy Pattern? Our Logging design is now far simpler and cleaner than it would have been using sub classing alone. Any potential code duplication has been prevented. Adding a new Formatter or a new Logging output option only requires ONE extra class. We have created a new class type independent of Logger, the Formatter, which improves potential reuse. The benefits ensure that the Strategy Pattern is one a programmer will certainly not want to forget.

Our simple implementation of the Strategy Pattern in the Logger example demonstrated both its simplicity and usefulness. It is a pattern which uses composition in favour of sub classing to reduce the complexity that may result from a growing class hierarchy where two or more class sub tasks are variable.

An important lesson to take from the Strategy Pattern implementation is that composition is something every programmer should be aware of. Sub classing is an immensely useful tool but in some complex scenarios it is simply not a good choice.

Abstract Factory Pattern

2008-04-23T22:31:00.000+05:30

Introduction

If you have not already done so, read up on the Factory Pattern. The Abstract Factory pattern is often easy to misunderstand because its complexity in certain situations. Here we will present two examples, one simply to demonstrate the concept, and another showing a more typical in-depth use.

Consider a case where we have implemented a variety of Factories. These could be multiple Database Abstraction Factories or numerous types of Log Formatters and Log Writers (both from our Factory Pattern examples). The problem with having multiple Factories is that at some point we need to decide which Factory we are going to use. This decision can be based on some application setting, or be a consequence of some other internal logic. Assuming such logic is required every time we need to decide upon a Factory to use, we can simplify the decision making by abstracting it into a specialized class - an Abstract Factory.

Definition

Definition: An object implementing the Abstract Factory Pattern creates Factories of a specific type which in turn are used to create concrete objects of a specific type.

The definition above may vary. The use of the Abstract Factory Pattern can differ among implementations. In many cases the AbstractFactory will create a concrete Factory and control its use internally rather than simply passing the Factory back to the client. In the examples below we assume the client simply want to get hold of the actual concrete Factory object to use themselves.

A PHP 5 Example

The Abstract Factory Pattern is difficult to explain with a simple example (yet). The result of the first part of our Implementation section however would be summarized as follows.

In creating an application, a development team has created a small framework (a collection of commonly used components) to speed production. The framework requires a great deal of flexibility, including the ability to switch between two or more database abstraction libraries based on a configuration option. Each database abstraction library has a dedicated Factory class to manage its instantiation and setup details (abstraction of creational logic).

To decide which of these Factories (and hence which library) to utilize a switch statement is written. Unfortunately, as time passes, the switch statement ends up being copied to several areas of the framework. To remove this code duplication, the logic to determine which Factory to utilize is consolidated in a specialised class. This class will determine which Factory should be used and return an instance of the Factory for developers to use.

This specialised class is an Abstract Factory; it creates a concrete Factory object from a family of related Factories (database abstraction) which are then used to create database abstraction objects.

php

// instantiate Abstract Factory
$abstractfactory = new DB_Abstraction_AbstractFactory();

// fetch a concrete Factory (decision handled by Abstract Factory static method)
$factory = $abstractfactory::getFactory();

// use concrete Factory to create a database connection object from
// the selected database abstraction library
$db = $factory->createInstance();

Implementing the Abstract Factory Pattern

Let's return to our Factory Pattern example of a Database Abstraction library. Where we left off, we had created a Factory for the ADOdb Lite library which handled all the details and murky logic of creating a useable connection object to perform database operations. As we previously mentioned, some member of our team working on the application may decide they need to utilise an alternative library such as PEAR::MDB2. Obviously this is a simple matter of creating a new MDB2 Factory.

Of course things are never that simple :). Now that we are planning for two related Factory objects, we should keep in mind that duplicated code is troublesome. To avoid this we should consider adding a Parent class which will contain all source code we expect to be common to both the ADOdb Lite and MDB2 Factories.

The result of this process is a parent abstract class "DB_Abstraction_Factory" and two concrete child classes, "DB_Abstraction_Factory_ADODBLITE" and "DB_Abstraction_Factory_MDB2". Also included is an interface. The interface is optional, however in following the design pattern principle //'code to an interface, not an implementation//' we realize that all Factories should follow the same interface if we are to allow the possibility of using an Abstract Factory.

The code for the above would look similar to:

php

interface iFactory {

  public function createInstance();

}

abstract class DB_Abstraction_Factory {

  protected $settings = array();

  protected function __construct() {
      $this->settings = Settings::getInstance();
  }

  abstract public function createInstance();

}

class DB_Abstraction_Factory_ADODB extends DB_Abstraction_Factory implements iFactory {

  public function __construct() {
      parent::__construct();
  }

  public function createInstance() {
      require_once('/path/to/adodb_lite/adodb.inc.php');
      $dsn = $this->settings['db.dsn'];
      $db = ADONewConnection($dsn);
      return $db;
  }

}

class DB_Abstraction_Factory_MDB2 extends DB_Abstraction_Factory implements iFactory {

  public function __construct() {
      parent::__construct();
  }

  public function createInstance() {
      require_once 'MDB2.php';
      $dsn = $this->settings['db.dsn'];
      $db = MDB2::factory($dsn);
      return $db;
  }

}

These simple Factories look almost too simple, but I can assure you the logic in loading ADOdb Lite plugins can be fairly complex once you decide to use them.

With our two Factories in their neat structure with a common abstract parent class, the code in which we will use the Factories will now need to decide which Factory (and hence which library) to use. A simple switch statement will handle this nicely, since the library type will be a configuration option. However what happens when this decision needs to be made across multiple classes? We end up with a duplicated switch statement and if we decide to add a new library we will need to locate and edit every copy of the statement.

To remove this duplication and consolidate the decision, we can create a specialized class - our Abstract Factory.

php

interface iAbstractFactory {

  public static function getFactory();

}

class DB_Abstraction_AbstractFactory implements iAbstractFactory {

  private function __construct() {

  }

  public static function getFactory() {
      $settings = Settings::getInstance();
      require_once('iFactory.php');
      require_once('DB_Abstraction_Factory.php');
      switch($settings['db.library'])
      {
          case 'adodblite':
              require_once('DB_Abstraction_Factory_ADODBLITE.php');
              $factory = new DB_Abstraction_Factory_ADODBLITE();
          break;
          case 'mdb2';
              require_once('DB_Abstraction_Factory_MDB2.php');
              $factory = new DB_Abstraction_Factory_MDB2();
          break;
      }
      return $factory;
  }

}

The Abstract Factory now consolidates all that decision making for which library to use and leaves our code free to ignore specific implementations, i.e. it needn't know the name of the Factory to use since all Factories use the same predictable interface. Code to an interface, not an implementation.

Our client code is now simplified to a large extent. We have consolidated creational logic to Factories, and even consolidated the decision on which library/Factory to use to an Abstract Factory. The only code we require to utilize this new structure is almost ridiculously simple.

php

// instantiate Abstract Factory
$abstractfactory = new DB_Abstraction_AbstractFactory();

// fetch a concrete Factory (decision handled in Abstract Factory static method)
$factory = $abstractfactory::getFactory();

// use concrete Factory to create a database connection object from
// the selected database abstraction library
$db = $factory->createInstance();

Disadvantages

To be added

Conclusion

Situations may arise where multiple Factories exist to create objects with similar responsibilities but with varying creational logic. In such situations, further simplification of object creation might be introduced using the Abstract Factory Pattern. The Abstract Factory pattern free client code from worrying about specific implementations and lets Abstract Factories and concrete Factories do all the hard work.

This consolidation of logic can be expanded into more complex scenarios where multiple Factories exist, and we need to simplify the logic which determines which Factory should be used. In some cases Factories may group families of many related classes in which case the Abstract Factory pattern graduates from a simplification to a near requirement.

Registry Pattern

2008-04-23T22:26:00.000+05:30

Introduction

The Registry is one of those Patterns where once you understand it, it seems so incredibly useful. Think of it as a basket; using a Registry you can add data (both values and objects) to the basket, and retrieve them as required from other parts of an application. Since all such data is handled by a single Registry object, it makes passing data and objects around an application far more simple than passing all such values as individual parameters to a constructor or setup method. In a similar fashion, a Registry can replace the need to have every object you need global access to acting as a Singleton.

The Registry itself can either be passed around as a parameter or it can be turned into a Singleton to enable global access to it from anywhere in an application. Where it is used to replace numerous Singletons, it can replace the need to know each individual class name which often makes it easier to reuse classes in other applications.

Definition

Definition: The Registry Pattern allows the storing and retrieval of data and objects which need to be accessed globally in a single centralised object.

A PHP 5 Example

At a minimum a Registry allows data to be registered and retrieved, often allowing the setting of a label for the value being registered. One of the most common types of data to use a Registry for are objects for which global access from other objects is required.

This simple PHP 5 example implements a private array to store objects and four methods for registering, unregistering, retrieving and checking the existence of objects.

php

class My_Registry {

   private $store = array();

   public function __construct() {

   }

   public function register($label, $object) {
       if(!isset($this->store[$label]))
       {
           $this->store[$label] = $object;
       }
   }

   public function unregister($label) {
       if(isset($this->store[$label]))
       {
           unset($this->store[$label]);
       }
   }

   public function get($label) {
       if(isset($this->store[$label]))
       {
           return $this->store[$label];
       }
       return false;
   }

   public function has($label) {
       return isset($this->store[$label]);
   }

}

In addition to the traditional methods, as of PHP 5.1 you can take advantage of the full suite of magic methods to allow.

php

class My_Registry {

   private $store = array();

   public function __construct() {

   }

   public function __set($label, $object) {
       if(!isset($this->store[$label]))
       {
           $this->store[$label] = $object;
       }
   }

   public function __unset($label) {
       if(isset($this->store[$label]))
       {
           unset($this->store[$label]);
       }
   }

   public function __get($label) {
       if(isset($this->store[$label]))
       {
           return $this->store[$label];
       }
       return false;
   }

   public function __isset($label) {
       if(isset($this->store[$label]))
       {
           return true;
       }
       return false;
   }

}

This could then be used as:

php

$reg = new My_Registry();
$reg->myObject = new SomeObject();
if (isset($reg->myObject)) {
   // there is a myObject value
} else {
   // there is not a myObject value
}
$obj = $reg->myObject;
unset($reg->myObject);

Implementing the Registry Pattern

Our Registry class "My_Registry" is actually very simple. It supplies methods for registering and unregistering objects, fetching an object known by a "label" string, and in addition lets us check if any object has been registered under a particular label. All objects which are registered are stored in a simple associative array indexed by the labels set at registration. Using labels is optional - one could also retrieve objects by checking their class type via is_a() although this limits the number of objects that can be registered to one of each type.

With the Registry now setup, we can start using it in other objects. I'll quickly note that unlike the Singleton Pattern examples, the Settings class (below) is no longer a Singleton. By using a Registry we can avoid using multiple Singletons to enable global access to objects. Our example is the same as the one for the Singleton Pattern except we have replaced the use of a Singleton with our new Registry.

php

class DB_Abstraction_MYSQLI {

   private $settings = null;

   public function __construct($registry) {
       // Settings already exists with imported settings data
       // Fetch pre-existing object using the Registry
       $this->settings = $registry->get('settings');
   }

   public function connect() {
       $conn = mysqli_connect(
           $this->settings->get('db.host'),
           $this->settings->get('db.username'),
           $this->settings->get('db.password'),
           $this->settings->get('db.database')
       );
       return $conn;
   }

   // ...

}

We can use this class as follows, see how we setup the Registry at the start. We register a Settings object which can later be retrieved for use in other objects.

Using the My_Registry class is as simple as:

php

// setup the registry
$registry = new My_Registry();

// instantiate an object we need global access to (Settings)
$settings = new Settings();
$settings->import('/app/settings.ini');

// register the object for global access
$registry->register('settings', $settings);

// create our abstraction object for use (retrieves Settings from My_Registry)
$db = new DB_Abstraction_MYSQLI($registry);

The Singleton Registry

In the example above, we passed the Registry in as a constructor parameter. An alternative method, which removes the need for constructor parameters is to make the My_Registry object a Singleton. As is common with Design Patterns, combining two or more Patterns often leads to even more useful solutions.

The changes required for our My_Registry class to follow the Singleton Pattern is simple. We just add a new My_Registry::getInstance() method to use a new static class property My_Registry::thisInstance, and make the class constructor private.

php

class My_Registry {

   private $store = array();

   static private $thisInstance = null;

   private function __construct() {

   }

   static public function getInstance() {
       if(self::$thisInstance == null)
       {
           self::$thisInstance = new My_Registry();
       }
       return self::$thisInstance;
   }

   public function register($label, $object) {
       if(!isset($this->store[$label]))
       {
           $this->store[$label] = $object;
       }
   }

   // ...

}

To use the Registry we now utilise its Singleton method:

php

// instantiate the registry using Singleton method
$registry = My_Registry::getInstance();

$settings = new Settings();
$settings->import('/app/settings.ini');

$registry->register('settings', $settings);

// no need to pass Registry as a parameter
$db = new DB_Abstraction_MYSQLI();

The change to our Database Abstraction class is equally simple:

php

class DB_Abstraction_MYSQLI {

   private $settings = null;

   public function __construct() {
       // get Singleton My_Registry object
       $registry = My_Registry::getInstance();
       $this->settings = $registry->get('settings');

  }

  // ...

}

Disadvantages

Patterns are not perfect in all situations and the Registry pattern is no exception. It helps simplify our source code but there are issues to watch out for. For one thing, the use of a Singleton Registry replaces numerous Singletons but still has a global nature. This is warning enough to be careful using the Registry.

Passing it as a constructor may often be preferable since it restricts access to the Registry to those objects which need it. This may not be possible in all cases however.

The Registry poses another issue when it comes to Unit Testing. When unit testing, a developer may setup arbitrary test data in a Registry which the class being tested will utilise once instantiated as an object. However when we implement a Singleton Registry we end up with a situation where creating new Registry objects is not possible - instead every call to My_Registry::getInstance() will return a reference to the exact same object each time - complete with any previously set data.

There are a few solutions to this problem. One could implement a clear() method to delete all Registry values for each new test, or one could implement an array stack (basically a multidimensional array) with non-test data stored to array key 0, and arbitrary test data stored to subsequent numbered keys while providing a mechanism for switching between each stack member. This sounds horribly complicated, however a simple example of our Registry with a stack follows (borrowed liberally from http://www.phppatterns.com).

php

class My_Registry {

   private $store = array(array()); // array[0]=>array[...]

   static private $thisInstance = null;

   private function __construct() {

   }


   static public function getInstance() {
       if(self::$thisInstance == null)
       {
           self::$thisInstance = new My_Registry();
       }
       return self::$thisInstance;
   }

   public function register($label, $object) {
       if(!isset($this->store[0][$label]))
       {
           $this->store[0][$label] = $object;
       }
   }

   public function unregister($label) {
       if(isset($this->store[0][$label]))
       {
           unset($this->store[0][$label]);
       }
   }

   public function get($label) {
       if(isset($this->store[0][$label]))
       {
           return $this->store[0][$label];
       }
       return false;
   }

   public function has($label) {
       return isset($this->store[0][$label];
   }

   // Test friendly isolation methods for original data

   public function backup() {
       // move $store[0] to $store[1]
       array_unshift($this->store, array());
   }

   public function restore() {
       // remove $store[0], restore $store[1] to it pre-backup() position
       array_shift($this->store);
   }

}

The main difference in the above is that original data is now stored to My_Registry::store[0] which is the first element in a multidimensional array. This lets us shift original data to another numbered key and back - thus emulating a easy backup and restore ability. These method will ensure that Unit Tests accompanying our source code will not be contaminated by data previously added to a Singleton Registry.

Conclusion

We have now covered the Registry Pattern and it close relative, the Singleton Registry, in some detail. We have seen how this Pattern can help remove the need for many objects to utilise the Singleton Pattern while at the same time enabling us additional control over how to inject objects into other objects as dependencies. The Registry is a common solution for allowing objects to access other objects without needing to pass them all as individual parameters to calling object's constructor method. We have also demonstrated how the Registry can be adapted to facilitate Unit Testing of classes using the Registry without being impacted by data set in prior tests.

Having now covered two methods of handling the inclusion of objects into other objects, the third Pattern remaining to be explored is the ServiceLocator. Another method coming into popular discussion in PHP forums is Dependency Injection which we may cover in the future.

PHP Design Patterns

2008-04-12T00:46:00.002+05:30

Patterns Using PHP

Design patterns are basically a general method that can be used in solving a variety of different problems.

What are Design Patterns

Design Patterns are simply defined solutions to common problems. Design patterns are not created by someone who sits in a room and decides to make a design pattern instead design patterns are proven solutions that are implemented over and over again through different projects. This re-use of the solution itself becomes a pattern. Don't be intimidated by the fancy names given to design patterns, such as façade, singleton or observer, they are exactly that just fancy names given to repeatable solutions.

What Design Patterns Are NOT

A design pattern is NOT a template rather a proposed solution that is not implementation specific. In other words you can take the same design pattern and implement it with any language, of course if the design pattern is an OO design pattern you need to implement it with an object-oriented language. More importantly the implementation itself may vary from project to project because of project restraints and requirements.
A design pattern is NOT a framework, though depending on whom you speak to, a group of design patterns maybe considered as a design framework.

Why Use Design Patterns

Most PHP developers may first ask why use Design Patterns or why design in the first place. After all PHP is a scripting language usually used for simple web development, aren’t functions are good enough?

Yes this is probably true if you work alone on small projects. But you will find Design and Design Patterns are beneficial in regards of:

Maintenance
Documentation
Readability
Easy when developing in large development teams
Developing Code to be used by other then yourself

Most enterprise applications that succeed are because of the fact that a good methodology and development process is in place, and apart of that comes design and with design more then likely comes design patterns.

However there is a trade off with design patterns because it adds another layer/component of abstraction there maybe a loss in performance and efficiency. Granted this may not be noticeable on high-end servers, but could be problem on low-end servers.

Some common PHP Patterns

Some other design patterns

Singleton Pattern

2008-04-12T00:45:00.002+05:30

Introduction

The Singleton is one of the simplest Patterns to understand. It's common usage is to ensure that only one instance of a class is ever instantiated. The reason for wanting such behaviour varies but typically it is because only one object instantiated from the source class is required and you want the resulting object to be available throughout an application, i.e. globally available.

An example might be a class for storing Settings. A Settings class is a good candidate for a Singleton because its data is immutable (the only way to change settings data is to edit the settings file) and it is likely required in many areas of an application. Furthermore creating a new Settings object wherever it is needed is wasteful of resources - each is identical to all others.

Definition

Definition: The Singleton Pattern proposes a static method for creating an instance of a class in such a way that once instantiated further calls to the same static method return a reference to the original instantiated object.

A PHP 5 Example

An example for PHP5 (without specific Settings methods implemented):

php

class Settings {

private $settings = array();

private static $_instance = null;

private function __construct() {
 // private constructor restricts instantiaton to getInstance()
}

protected function __clone() {
 // restricts cloning of the object
}

static public function getInstance() {
 if(is_null(self::$_instance))
 {
     self::$_instance = new self();
 }
 return self::$_instance;
}

public function import() {
 // ...
}

public function get() {
 // ...
}

}

Implementing the Singleton Pattern

The key to implementing a Singleton is utilising a static variable; a variable whose value remains constant even when execution leaves its variable scope. This stores the object originally instantiated between calls to the static method Settings::getInstance(), and returns a reference to it on each subsequent call to the method.

Also note that the constructor is usually made private. To ensure only one Settings object is ever used, we should restrict access to the constructor to prevent a new object being created in error. This specific restriction is not possible in PHP 4 so bear this in mind.

The Singleton also requires careful consideration before use. It is by nature very similar to a global variable - the static method is available from anywhere in the application once the file containing the class is included. This can create problems similar to those experienced with global variables - and so should be used with some degree of care. The near global nature of the Singleton has led to it being referred to on occassion as an "Anti Pattern" since it is easily misused as an alternative to making data global.

Using a Singleton is as simple as calling its static getInstance() method.

php

// fetch settings from INI file
$settings = Settings::getInstance();
$settings->import('/app/settings.ini');

// we can now use the Settings object somewhere else, e.g. database class
class DB_Abstraction_MYSQLI {

private $settings = null;

public function __construct() {
 // Settings already exists with imported settings data
 // Fetch pre-existing object via Singleton method
 $this->settings = Settings::getInstance();
}

public function connect() {
 $conn = mysqli_connect(
     $this->settings->get('db.host'),
     $this->settings->get('db.username'),
     $this->settings->get('db.password'),
     $this->settings->get('db.database')
 );
 return $conn;
}

// ...

}

The alternative to using the Singleton is of course to instantiate a Settings object, and import the settings INI file again. However doing so only wastes resources since the data is immutable and identical to that held in all such objects. Why have a dozen identical Settings objects when you only need one?

Disadvantages

The Singleton is not without its disadvantages. We have already noted that its global nature can cause problems similar to using global variables and encourage misuse without care. It can also make the practice of Unit Testing more difficult. Unit Testing typically tests individual objects. In testing the DB_Abstraction class above, a programmer may wish to "mock" the Settings object (i.e. insert a fake object with known return values). This is useful in cases where the Settings class may not even yet exist, and we need to emulate it.

One solution, is to amend the class so that a developer may optionally pass a Settings object as a paramater into the constructor. The code for this may look similar to:

php

class DB_Abstraction_MYSQLI {

// ...

public function __construct($settings=null) {
 $this->settings = is_null($settings) ? Settings::getInstance() : $settings;
}

// ...

}

This allows more flexible testing since a developer can optionally override the default behaviour of using the Settings class Singleton method, and replace it with any arbitrary Settings object they choose to facilitate testing.

Singletons for PHP 4

PHP 4 does not support static properties/variables in classes. As a result the method of implementing Singletons differ slightly. Rather than use a class property, we instead use a static variable from within the Singleton getInstance() method. In addition, PHP 4 does not support access keywords for class properties or methods. This means that PHP 4 constructors will always be available in addition to the Singleton method of instantiation.

An example of a PHP 4 Singleton implementation follows:

php

class Settings (

$settings = array();

function Settings() {
 // no support for "private" keyword
}

function &getInstance() {
 static $thisInstance;
 if(!isset($thisInstance[0]))
 {
     $thisInstance = array();
     $thisInstance[0] =& new Settings();
 }
 return $thisInstance[0];
}

function import() {
 // ...
}

function get() {
 // ...
}

}

You can retrieve the instance with

php

mySettings =& Settings::getInstance();

Other version

php

class MyClassUsedAsSingleton
{
var $_value;

function MyClassUsedAsSingleton ($directCall=true)
{
 if ($directCall) {
     trigger_error("MyClassUsedAsSingleton is singleton!", E_USER_ERROR);
 }
}

function &getInstance()
{
 static $instance;
 if (!is_object($instance)) {
     $instance = new MyClassUsedAsSingleton(false);
 }
 return $instance;
}

function set($value)
{
 $this->_value = $value;
}

function get()
{
 return $this->_value;
}

function isDefined()
{
 if (is_null($this->_value)) {
     return false;
 }
 return true;
}
}
// static access
function setValue($value)
{
$object =& MyClassUsedAsSingleton::getInstance();
$object->set($value);
}

function getValue()
{
$object =& MyClassUsedAsSingleton::getInstance();
return $object->get();
}

function isValueDefined()
{
$object =& MyClassUsedAsSingleton::getInstance();
return $object->isDefined();
}
// use
function changeValue()
{
setValue("New Value");
}

if (!isValueDefined()) {
setValue("Default Value");
}
echo getValue();
changeValue();
echo getValue();

Note: Due to the way in which PHP 4 implements static variables, a static variable cannot hold a reference to a value throughout execution. However a static variable array element can. See References with global and static variables for more information.

Singleton Function

Another way to get a singleton of a class, without actually adding any additional code to the class is to use a function that will return or make a new instance of said class.

php

function singleton($class)
{
// Static Array Holding All Instances of Singleton Classes
static $Instances = array();
if(!isset($Instances[$class])){
 $Instances[$class] = new $class();
}
return $Instances[$class];
}

Conclusion

Singletons as we have seen are a useful Design Pattern when used with care. They allow a single instance of any object to be globally available within an application. Implementation is possible in all current PHP versions, although constructor restriction is not possible in PHP 4. We have also covered how the Pattern can pose problems when unit testing, and how to overcome these with some small amendments (what some people like to call "loose wiring").

The Singleton is not the only method for sharing objects across an application. Two other useful Patterns to examine are the Registry and ServiceLocator. Another method coming into popular discussion in PHP forums is Dependency Injection.

Factory Pattern

2008-04-12T00:45:00.001+05:30

Introduction

At some point in PHP development, programmers will discover a need to simplify the creation of some objects. Perhaps the object simply requires a number of detailed steps to create, all of which must be duplicated for every new object of that type. To remove such code duplication and simplify the task, the Factory Pattern offers a solution. In fact the Factory Pattern is something many programmers may discover by themselves since it is a logical step to take all the detailed creational steps of an object and try bundling into a new object to handle the task.

The Factory Pattern can be applied as an individual class with sole responsibility for creating objects or as a single method within the object to be created (a Factory Method). In both cases, its purpose remains similar - to make creating an object easier.

Definition

Definition: An object implementing the Factory Pattern is an object which creates other objects of a specific type.

A PHP 5 Example

One family of objects whose creation may require numerous complex steps are from Database Abstraction libraries such as the ADOdb Lite or PEAR::MDB2. These libraries involve instantiating a connection object, allowing plugin use, and connecting to a database using configuration options. The steps involved can range from simple two liners to using complex logic depending on the scenario and plugins required.

Simplifying this process makes huge sense. One can write a dedicated Factory class to fetch configuration options and perform the instantiation and plugin tasks transparently (based on those options). A simple Factory interface and implementing class (with minimal tasks) for ADOdb Lite might look similar to:

php

interface iFactory {

public function createInstance();

}

class DatabaseAbstractionFactory implements iFactory {

private $settings = array();

public function __construct() {
   // Settings class from our Singleton Pattern example
   $this->settings = Settings::getInstance();
}

public function createInstance() {
   require_once('/path/to/adodb_lite/adodb.inc.php');
   $dsn = $this->settings['db_dsnstring'];
   // do lots of complicated stuff for adding plugins
   $db = ADONewConnection($dsn);
   return $db;
}

}

Implementing the Factory Pattern

Of course, there are many other similar uses for a Factory. All that is required is that the Factory consolidate all the logic required to create an object. In the case above we have a single complex creation process for a Database Abstraction library's connection object. Another situation where a Factory is of use is where different objects of the same family must be created depending on some value.

For example, we may have a Logging utility which is capable of outputting a log message either to the browser or to the command line. Or perhaps we want it stored for later viewing to a file. The typical logic used within our calling class to determine which to use may be similar to:

php

switch($outsetting)
{
case 'echo':
   $out = new Output_Echo();
   break;
case 'cli':
   $out = new Output_CLI();
   break;
case 'file':
   $out = new Output_File();
}

This would work at first. But what happens if we decide we need to store the log message for later viewing in a database? Or maybe a client wants it output as formatted XML? As the options grow, this switch statement is growing ungainly. Worse, we may be replicating this piece of code across numerous classes which handle the initial generation or formatting of the log message. Any changes would need to be manually updated to all those classes.

The Factory Pattern suggests this creational logic should be isolated within its own class (the Factory) leaving the calling objects free to do their stuff and let the Factory worry about what Output object might be required.

The result may look similar to:

php

interface iFactory {

public function createInstance();

}

class Output_Factory implements iFactory {

private $settings = array();

public function __construct() {
   $this->settings = Settings::getInstance();
}

public function createInstance() {
   $outsetting = $this->settings->get('out.target');
   switch($outsetting)
   {
       case 'echo':
           $out = new Output_Echo();
           break;
       case 'cli':
           $out = new Output_CLI();
           break;
       case 'file':
           $out = new Output_File();
   }
   return $out;
}

}

With all the troublesome logic hidden from the calling object and a standard interface implemented that is common to all Output classes, out calling classes (however many we have) are free to ignore everything except getting an Output class via the Factory and telling it to write something...

php

class My_Log {

private $output = null;

public function __construct() {
   $factory = new Output_Factory();
   $this->output = $factory->createInstance();
}

public function log($message) {
   $this->output->write($message);
}

}

If creating the Factory manually turns annoying (being one extra line, and all programmers being exceptionally lazy), you could bundle the Settings class retrieval into the createInstance() method on the Factory class and make it a static method.

Disadvantages

The Factory Pattern is a common pattern to see implemented. It is a logical method of isolating the logic for creating a class, or the logic for deciding which concrete subclass of a family to instantiate. In this capacity it has few disadvantages. Some problems may arise when complex creational logic of various types co-exist - i.e. where it becomes necessary to utilise two or more Factory classes.

One example might be our Database Abstraction Factory. It's sole purpose is to churn out ADOdb Lite connection objects applying configuration options, loading required plugins (if such added), etc. If someone were to decide that they needed access to PEAR::MDB2 or the traditional ADOdb library then the creational logic for instantiation and plugin loading would differ. Although this new piece of logic (deciding which library to use) could be integrated into the existing Factory class - it would simply turn into a very complex switch statement.

A solution to this scenario, the Abstract Factory Pattern, is discussed in another entry. The Abstract Factory abstracts the logic of choosing which Factory to use in creating a new object. Sound complicated? It's not :).

Conclusion

In covering the Factory Pattern we have covered a lot of ground. Creating objects can range from simple to complex, and the Factory Pattern provides a solution for isolating such creational logic in centralised class to allow easier object creation by client classes and prevent code duplication. Although we saw two varied situations where the Factory Pattern was useful, the Pattern can prove useful in many situations that call for the creation of an object.

Also noted is that situations may arise where multiple Factories exist to create objects with similar responsibilities but with varying creational logic. In such situations, further simplification of object creation might be introduced using the Abstract Factory Pattern.

Facade Pattern

2008-04-12T00:43:00.000+05:30

Introduction

At some point in PHP development, programmers will discover a need to:

make a software library easier to use and understand, since the facade has convenient methods for common tasks;
make code that uses the library more readable, for the same reason;
reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system;
wrap a poorly designed collection of APIs with a single well-designed API (As per task needs).

In the Facade Pattern a class hides a complex subsystem from a calling class. In turn, the complex subsystem will know nothing of the calling class.

Definition

Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. This can be used to simplify a number of complicated object interactions into a single interface.

Example

In this example, the CaseReverseFacade class will call a subsystem to reverse the case of a string passed from the Book class. The subsystem is controlled by the reverseCase function in the CaseReverseFacade, which in turn calls functions in the ArrayCaseReverse and ArrayStringFunctions classes. As written, the CaseReverseFacade can reverse the case of any string, but it could easily be changed to only reverse a single element of a single class.

In my example I make all elements of the Facade and the subsystem static. This could also easily be changed.

Book.php

php

class Book {

  private $author;
  private $title;

  function __construct($title_in, $author_in) {
    $this->author = $author_in;
    $this->title  = $title_in;
  }

  function getAuthor() {return $this->author;}

  function getTitle() {return $this->title;}

  function getAuthorAndTitle() {
    return $this->getTitle() . ' by ' . $this->getAuthor();
  }

}

CaseReverseFacade.php

php

class CaseReverseFacade {

  public static function reverseStringCase($stringIn) {

    $arrayFromString =
    ArrayStringFunctions::stringToArray($stringIn);

    $reversedCaseArray =
    ArrayCaseReverse::reverseCase($arrayFromString);

    $reversedCaseString =
    ArrayStringFunctions::arrayToString($reversedCaseArray);

  return $reversedCaseString;

  }

}

ArrayCaseReverse.php

php

class ArrayCaseReverse {

private static $uppercase_array =
  array('A', 'B', 'C', 'D', 'E', 'F',
        'G', 'H', 'I', 'J', 'K', 'L',
        'M', 'N', 'O', 'P', 'Q', 'R',
        'S', 'T', 'U', 'V', 'W', 'X',
        'Y', 'Z');

private static $lowercase_array =
  array('a', 'b', 'c', 'd', 'e', 'f',
        'g', 'h', 'i', 'j', 'k', 'l',
        'm', 'n', 'o', 'p', 'q', 'r',
        's', 't', 'u', 'v', 'w', 'x',
        'y', 'z');

  public static function reverseCase($arrayIn) {
    $array_out = array();

  for ($x = 0; $x < count($arrayIn); $x++) {
    if (in_array($arrayIn[$x], self::$uppercase_array)) {
        $key = array_search($arrayIn[$x], self::$uppercase_array);
   $array_out[$x] = self::$lowercase_array[$key];
    } elseif (in_array($arrayIn[$x], self::$lowercase_array)) {
        $key = array_search($arrayIn[$x], self::$lowercase_array);
   $array_out[$x] = self::$uppercase_array[$key];
 } else {
   $array_out[$x] = $arrayIn[$x];
 }
  }
  return $array_out;
  }

}

ArrayStringFunctions.php

php

class ArrayStringFunctions {

  public static function arrayToString($arrayIn) {
    $string_out = NULL;
  foreach ($arrayIn as $oneChar) {
    $string_out .= $oneChar;
  }
  return $string_out;
  }

  public static function stringToArray($stringIn) {
    return str_split($stringIn);
  }

}

testFacade.php

php

include_once('ArrayCaseReverse.php');
include_once('ArrayStringFunctions.php');
include_once('Book.php');
include_once('CaseReverseFacade.php');

echo tagins("html");
echo tagins("head");
echo tagins("/head");
echo tagins("body");

echo "BEGIN TESTING FACADE PATTERN";
echo tagins("br").tagins("br");

$book =
  new Book("Design Patterns",
            "Gamma, Helm, Johnson, and Vlissides");

echo "Original book title: ".$book->getTitle();
echo tagins("br").tagins("br");

$bookTitleReversed =
  CaseReverseFacade::reverseStringCase($book->getTitle());

echo "Reversed book title: ".$bookTitleReversed;
echo tagins("br").tagins("br");

echo "END TESTING FACADE PATTERN";
echo tagins("br");

echo tagins("/body");
echo tagins("/html");

//doing this so code can be displayed without breaks
function tagins($stuffing) {
  return "<".$stuffing.">";
}

output of testFacade.php

php

BEGIN TESTING FACADE PATTERN


Original book title: Design Patterns


Reversed book title: dESIGNpATTERNS


END TESTING FACADE PATTERN