Registry design pattern...good or bad?

Question

The following code is from a tutorial (http://net.tutsplus.com/php/creating-a-php5-framework-part-1/), not mine.

I have a few questions about this code...

• The article claims it is using the "registry design pattern"; is that the universal name for this design in the industry?
• Is there another similar patter out there that would be a better option?
• Is this pattern considered to be good practice to implement in the context of an MVC framework?

I just want to figure out if I should use this design pattern in my own implementation of a MVC framework. Thanks!

<?php
/**
 * The PCARegistry object
 * Implements the Registry and Singleton design patterns
 * @version 0.1
 * @author Michael Peacock
 */
class PCARegistry {

/**
 * Our array of objects
 * @access private
 */
private static $objects = array();

/**
 * Our array of settings
 * @access private
 */
private static $settings = array();

/**
 * The frameworks human readable name
 * @access private
 */
private static $frameworkName = 'PCA Framework version 0.1';

/**
 * The instance of the registry
 * @access private
 */
private static $instance;

/**
 * Private constructor to prevent it being created directly
 * @access private
 */
private function __construct()
{

}

/**
 * singleton method used to access the object
 * @access public
 * @return 
 */
public static function singleton()
{
 if( !isset( self::$instance ) )
 {
  $obj = __CLASS__;
  self::$instance = new $obj;
 }

 return self::$instance;
}

/**
 * prevent cloning of the object: issues an E_USER_ERROR if this is attempted
 */
public function __clone()
{
 trigger_error( 'Cloning the registry is not permitted', E_USER_ERROR );
}

/**
 * Stores an object in the registry
 * @param String $object the name of the object
 * @param String $key the key for the array
 * @return void
 */
public function storeObject( $object, $key )
{
 require_once('objects/' . $object . '.class.php');
 self::$objects[ $key ] = new $object( self::$instance );
}

/**
 * Gets an object from the registry
 * @param String $key the array key
 * @return object
 */
public function getObject( $key )
{
 if( is_object ( self::$objects[ $key ] ) )
 {
  return self::$objects[ $key ];
 }
}

/**
 * Stores settings in the registry
 * @param String $data
 * @param String $key the key for the array
 * @return void
 */
public function storeSetting( $data, $key )
{
 self::$settings[ $key ] = $data;


}

/**
 * Gets a setting from the registry
 * @param String $key the key in the array
 * @return void
 */
public function getSetting( $key )
{
 return self::$settings[ $key ];
}

/**
 * Gets the frameworks name
 * @return String
 */
public function getFrameworkName()
{
 return self::$frameworkName;
}


}

?>

Answer 1

The article claims it is using the "registry design pattern"; is that the universal name for this design in the industry?

Yes, but the implementation could obviously differ. Basically, a registry is a container for shared objects. In the really basic version, you could use an array. As such, the variable $GLOBALS could be called a registry.

Is there another similar patter out there that would be a better option?

There are two variations of a registry. There is the global registry (Which is far the most common, and which this is an example of). And there is a local registry. A local registry is passed to objects that need it, rather than obtained through a global symbol (static class, singleton etc.). A local registry has a lower degree of coupling, but is also slightly more abstract, so there is a tradeoff there.

You can also go even further and use full dependency injection, where you explicitly pass all dependency to the objects that needs them. This can be a bit tedious in larger applications. You can couple this with a dependency injection container, which is a piece of code that "knows" which dependencies which classes have. This is even more complex than a local registry, but has a very low degree of coupling.

Is this pattern considered to be good practice to implement in the context of an MVC framework?

It's common practise. If it's good or bad is a judgement call. Personally I'm willing to accept some complexity in return of decoupling, but ymmv.