As noted in the introduction, the first impression that some developers have when they hear about LSB is that it’s simply a minor, rather irrelevant improvement of the language. To demonstrate how useful this feature is in reality, I’m going to recreate a fictional scenario where it’s necessary to define a base abstract registry class, whose functionality and structure will be inherited and eventually refined by one or more subclasses. Simply put, the definition of this abstract registry will look as follows: (RegistryAbstract.php)
abstract class RegistryAbstract { protected static $_instances = array();
// get Singleton instance of the registry public static function getInstance() { $class = self::getClass(); if (!isset(self::$_instances[$class])) { self::$_instances[$class] = new $class; } return self::$_instances[$class]; }
public static function getClass() { return __CLASS__; }
// implemented by registry subclasses abstract public function set($key, $value);
// implemented by registry subclasses abstract public function get($key);
// implemented by registry subclasses abstract public function clear(); } As you can see, the previous “RegistryAbstract” class declares some abstract setter and getter methods that will allow you to create concrete child registries for fetching and saving data to a predefined storage mechanism, such as a vanilla array, a session variable or a database. Note the implementation of a static “getInstance()” method, which in theory returns a Singleton instance of the current registry via the “getClass()” method. Since this base abstract class should always be refined by one or multiple implementations, it’s time to derive a subclass from it, which in this case will be an array-based registry. Here’s the definition of this concrete class: (ArrayRegistry.php)
<?php
class ArrayRegistry extends RegistryAbstract { private $_data = array();
// save data to the registry public function set($key, $value) { $this->_data[$key] = $value; return $this; }
// get data from the registry public function get($key) { return isset($this->_data[$key]) ? $this->_data[$key] : null; }
// clear the registry public function clear() { $this->_data = array(); } } } Grasping the logic driving the previous “ArrayRegistry” class is a pretty straightforward process; it simply implements the abstract methods defined by its parent to store and retrieve data from a private array. I don’t want to sound pedantic, but apparently it looks like this concrete registry will work like a charm. Unfortunately, things can be really tricky sometimes, because the hard truth is that any attempt to call the class’s inherited “getInstance()” method will cause the PHP engine to throw a fatal error. But how is this possible if the method in question exactly returns an instance of the array registry? Well, in its current state, what the method really does is grab an instance of its parent, which is obviously a big problem, since this one is abstract. It’s probable, however, that this explanation sounds a bit confusing to you, so in the next section I’m going to code a hands-on example that will recreate the condition previously described. Now, to learn what’s wrong with the “ArrayRegistry” class, click on the link below and keep reading.
blog comments powered by Disqus |
|
|
|
|
|
|
|