The use of the magic accessors (__get and __set) have allowed for the rapid growth and expansion of objects beyond anyones wildest dreams and now we are paying severely for the bloat and overhead. On top of that, often coupled with this, is the lack of validation of values following overly optimistic assumptions about the values being set. Let me show an example of such a class to make this more clear:

class User
{
    protected $_data=array();

    public function &__get($key)
    {
        $value = null;
        if (isset($this->_data[$key])) {
            $value = $this->_data[$key];
        }

        return $value;
    }

    public function __set($key, $value)
    {
        $this->_data[$key] = $value;
    }

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

    public function __unset($key)
    {
        unset($this->_data[$key]);
    }
}

What this now affords developers is the ability to, anywhere in code where they have a User object instance, create arbitrary invalidated values on the User object:

for($i=0; $i<1000000; $i++) {
    array_push($user->foo, new Foo($i));
}
$user->bar = 45.352135;
$user->baz = 'I CAN HAZ ANY VALUE I WANT! MUHAHAHA!';
$user->bat = memcache_get('some_invalid_value_from_mc');
// ...
var_dump(strlen(serialize($user))); // => 134523592

My argument centers around the misuse of these magic accessors, particularly in the case where you are persisting the object (as would most likely be the case for a User object). If you have a value you are putting into an object you should be able to, in a very straightforward manner, validate it (see my post A Tailored Approach to Object Validation). What better way than to explicitly specify an instance variable and a getter and setter method for it? You can still use the magic accessors but perhaps as a catch all for values which seemed to appear out of thin air. Take, for example, the way I think most setups should be done or modeled to closely resemble:

class User
{
    protected $_name;
    protected $_age;
    /* ... */

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

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

    public function setAge($age)
    {
        $minimumAge = 0;
        $maximumAge = 130;
        $validator = new Validator_Integer_Between($minimumAge, $maximumAge);
        if (!$validator->valid($age)) {
            throw new ValidationException('The age attribute must be between the values [' . $minimumAge . '] and [' . $maximumAge . ']');
        }

        $this->_age = $age;
    }

    public function setName($name)
    {
        $regEx = "/^[A-Za-z]+$/";
        $validator = new Validator_String_Matches($regEx);
        if (!$validator->valid($name)) {
            throw new ValidationException('The name attribute must match the regular expression pattern [' . $regEx . ']');
        }

        $this->_name = $name;
    }

    public function __get($key)
    {
        throw new Exception('User::__get(' . $key . '): Attempt to get a non-existent attribute [' . $key . ']');
    }

    public function __set($key, $value)
    {
        throw new Exception('User::__set(' . $key . ', ' . $value . '): Attempt to set a non-existent attribute [' . $key . '] to value [' . $value . ']');
    }

    public function __isset($key)
    {
        throw new Exception('User::__isset(' . $key . '): Attempt to check for non-existent attribute [' . $key . ']');
    }

    public function __unset($key)
    {
        throw new Exception('User::__unset(' . $key . '): Attempt to unset a non-existent attribute [' . $key . ']');
    }
}

As you can see any value that “falls through the cracks” will be caught and dealt with. In this way we are able to implement any craziness in the magic accessors, should we ever need do anything “magical”, and use concrete getters and setters so we are able to more readily (and cleanly) allow for the validation of every value set into our object, not to mention its also faster. If you have a million values in your user object you should have at least two million accessor methods (1 million gets, and 1 million sets). Adding a new attribute to the class, creating its getter method, and its setter method forces you to think about what you are doing and whether you need the value or not.

Suppose, for a minute, you have the method “postError” on the object “$client” which is of type “RESTClient” and the static method “log” on the class “Logger”. To nicely wrap up both of these to receive a publish action denoted by the subject, say “invalid_password”, we would do the following:

// Setup the REST client
$client = new RESTClient('127.0.0.1', 80);

// Subscribe the REST client
Kestrel_PubSub::subscribe('invalid_password', $client, 'postError');

// Subscribe the Logger
Kestrel_PubSub::subscribe('invalid_password', 'Logger', 'log');

Later in the code where we want to publish to our subscribers, the string argument ‘Invalid password supplied’, we then simply do the following:

Kestrel_PubSub::publish('invalid_password', 'Invalid password supplied.');

That’s it! There are a few other API methods for managing these subscriptions, but shown here is the simplest use case. I should mention to those interested in this pattern that Matthew Weier O’Phinney’s A Simple PHP Publish-Subscribe System has a markedly similar implementation to this one and is worth researching depending on your needs. The one I have shown here, Kestrel PubSub, is a bare-bones implementation with very little object overhead and kept intentionally simplistic. The main difference of note between the two implementations, is that Matthew’s implementation returns a subscriber handle while mine does not. This is a nice convenience if you expect to remove subscribers, but I have yet to come up with the use case practically. Likewise discarding this convenience can greatly increase the simplicity and clarity. I did decide, at the last minute, to include an unsubscribe but instead of using a handle to unsubscribe a subscriber the unscubscribe method takes the original context in which the subscriber was added to remove it from the subscribers. I feel this is a very healthy compromise, but that could be subject to change as I continue to expand use of this pattern.

/**
 * Generic validation (e.g. code generated) would go here
 */
abstract class Foo_Abstract_Autogenerated
{
    public static function auto_validate_bar($bar)
    {
        $validator = new Validator_Integer_Between(1, 100);
        if ($validator->valid($bar)) {
            return true;
        }

        return false;
    }
}

/**
 * Custom validation (e.g. business logic / interdependencies ) would go here
 */
abstract class Foo_Abstract extends Foo_Abstract_Autogenerated
{
    public function validate_bar($bar)
    {
        if (in_array($bar, $this->_bannedBarValues)) {
            return false;
        }

        return true;
    }
}

class Foo extends Foo_Abstract
{
    protected $_bannedBarValues = array(1, 2, 3);

    public function valide($fieldName, $value)
    {
        if (method_exists($this, 'validate_' . $fieldName)) {
            $returnValue = call_user_func_array(array($this, 'auto_validate_' . $fieldName), $value);
            if ($returnValue) {
                $returnValue = call_user_func_array(array($this, 'validate_' . $fieldName), $value);
            }
        }

        return $returnValue;
    }
}

This now affords me the luxury of being able to do the following:

// Does a value validate in static context?
$bar = $_REQUEST['bar'];
$valid = Foo::auto_validate_bar($bar);

// Does a value validate against the business logic?
$bar = $_REQUEST['bar'];
$valid = $foo->validate_bar($bar);

// Does the current instance value validate against the business logic?
$valid = $foo->validate_bar($foo->bar);

// Does the current instance value validate against both generic and business logic?
$valid = $foo->validate('bar', $foo->bar);

Now I can afford myself the luxury of autogenerating a generic class, in similar fashion to Symfony validators, to accomplish the validation for the Foo object.

What do you folks think?