As I said in the introduction, the goal of the registry pattern is simply to provide client code with a mechanism which allows you to save and retrieve resources across different points of an application. Even though its implementation in PHP (and other languages) may vary from case to case, in general creating a basic registry using an object-oriented approach demands that you build a class containing the methods required to perform the saving/retrieval tasks. In consonance with the previous concepts, first I’m going to demonstrate how to apply the pattern in question by of creating an abstract registry class, whose concrete implementations (read: their eventual subclasses) will be tasked with storing and fetching resources by means of different persistence mechanisms. Having said that, here’s the definition of this abstract registry. Look at it, please: (AbstractRegistry.php)
<?php
abstract class AbstractRegistry { protected static $_instances = array();
// get Singleton instance of the registry (uses the 'get_called_class()' function available in PHP 5.3) public static function getInstance() { // resolves the called class at run time $class = get_called_class(); if (!isset(self::$_instances[$class])) { self::$_instances[$class] = new $class; } return self::$_instances[$class]; }
// overriden by some subclasses protected function __construct(){}
// prevent cloning instance of the registry protected function __clone(){}
// implemented by subclasses abstract public function set($key, $value);
// implemented by subclasses abstract public function get($key);
// implemented by subclasses abstract public function clear(); } If you closely analyze the above “AbstractRegistry” class, you’ll see that it’s nothing but a Singleton that defines a basic interface, whose methods must be properly implemented by all the concrete registries derived from it. I decided to make this abstract class a Singleton to restrict the point of access to each concrete registry; this small constraint, however, doesn’t prevent them from being used globally at different points of an application. Again, a word of warning is in order here: due to the global nature of the pattern, it should be applied with caution and responsibility. In addition, you may have noticed that the previous “getInstance()” method calls internally the “get_called_class()” function, available from PHP 5.3, which uses Late Static Bindings to determine at runtime which registry class should be invoked in a static context. This function makes creating hierarchy of Singletons a breeze, but if you still haven’t made the upgrade to that version of PHP, you’ll either have to implement this method within each concrete registry (a very annoying and inefficient approach) or make those registries non-Singletons. So far, so good. With an abstract registry neatly accommodated on top of the hierarchy, we now need to derive a concrete class from this parent, which permits us to save and fetch resources from a specific storage mechanism. With that idea in mind, in the following section I’m going to create a concrete registry that will save and retrieve a given resource from a plain array. To see how this whole new class will be defined, click on the link below and keep reading.
blog comments powered by Disqus |
|
|
|
|
|
|
|