The factory method pattern is a design pattern for creating objects. The factory is responsible for creating objects, that is, using the new keyword. Every time you create objects of a certain type you delegate the task to the factory.

Lets say we have a system that can invite contacts from different email providers. The factory code would look like something like this in PHP:

class InviterFactory
{
  public static function getInviter($type)
  {
    switch ($type)
    {
    case 'gmail':
      $inviter = new GmailInviter();
      break;
    case 'hotmail':
      $inviter = new HotmailInviter();
      break;
    case 'yahoo':
      $inviter = new YahooInviter();
      break;
    default:
      $inviter = null;
    }

    return $inviter;
  }
}

In the future, if we ever add another email provider, say, canada.com, we would only have to add the CanadaInviter to the factory class, and our whole project is now ready to use this type of inviter.

The factory pattern is also good for unit testing. In unit testing we want to completely be able to control a small section of the program to test all possible inputs and outputs. When testing a section of code that uses the factory to create objects, we can replace the standard factory with a unit-test factory, that returns dummy objects with only enough functionality required for testing that component.

Factory methods promote encapsulation. In our example each of the inviters have the same functionality to retrieving a contact list from the provider, but implement it differently.

interface Inviter
{
  public function getContacts();
}

class GmailInviter implements Inviter
{
  public function getContacts()
  {
    // code to get contacts
    return $contacts;
  }
}

class HotmailInviter implements Inviter
{
  public function getContacts()
  // ...
}

Now you can add the factory pattern to your programming tool belt. Note, this is just example code, real code has comments and error checking.

Related posts:

1. Quality Software @ Thirdi – PHP 5.3
2. Quality Software @ Thirdi – Symfony Checklist
3. Quality Software @ Thirdi – Mega Drop-Down Navigation Menus

Fortunately, there is an elegant solution. The idea is based on the Symfony CLI environment. At the top of the test script, add the following lines (or put them in a file and include that file):

<?php
require_once ‘PHPUnit/Framework.php’;

define(‘SF_ROOT_DIR’,      realpath(dirname(__file__).’/../..’));
define(‘SF_APP’,           ‘frontend’);
define(‘SF_ENVIRONMENT’,   ‘cli’);
define(‘SF_DEBUG’,          false);

require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.’apps’.
DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.’config’.
DIRECTORY_SEPARATOR.’config.php’);
?>

These lines should be familiar if you have worked with Symfony CLI. Basically, they are boilerplate code for any Symfony CLI app. With any luck, Symfony should load classes for you automagically.

Related posts:

1. Unit Tests vs. Functional Tests
2. My Laziness and sfPropelMigrationsLightPlugin
3. Quality Software @ Thirdi – Factory Method Pattern