Recipe 7.11. Overriding Property Accesses

7.11.1. Problem

You want handler functions to execute whenever you read and write object properties. This lets you write generalized code to handle property access in your class.

7.11.2. Solution

Use the magical methods __get( ) and __set( ) to intercept property requests.

To improve this abstraction, also implement __isset( ) and __unset( ) methods to make the class behave correctly when you check a property using isset( ) or delete it using unset( ).

7.11.3. Discussion

Property overloading allows you to seamlessly obscure from the user the actual location of your object's properties and the data structure you use to store them.

For example, the Person class shown in Example 7-30 stores variables in an array, $__data.

Implementing magic accessor methods

class Person {     private $__data = array();     public function __get($property) {         if (isset($this->__data[$property])) {             return $this->__data[$property];         } else {             return false;         }     }     public function __set($property, $value) {         $this->__data[$property] = $value;     } }

Example 7-31 shows how to use the Person class.

Using magic accessor methods

$johnwood = new Person; $johnwood->email = ''; // sets $user->__data['email'] print $johnwood->email;                 // reads $user->__data['email']

When you set data, __set( ) rewrites the element inside of $__data. Likewise, use __get( ) to trap the call and return the correct array element.

Using these methods and an array as the alternate variable storage source makes it less painful to implement object encapsulation. Instead of writing a pair of accessor methods for every class property, you use __get( ) and __set( ).

With __get( ) and __set( ), you can use what appear to be public properties, such as $johnwood->name, without violating encapsulation. This is because the programmer isn't reading from and writing to those properties directly, but is instead being routed through accessor methods.

The __get( ) method takes the property name as its single parameter. Within the method, you check to see whether that property has a value inside $__data. If it does, the method returns that value; otherwise, it returns false.

When you read $johnwood->name, you actually call __get('name') and it's returning $__data['name'], but for all external purposes that's irrelevant.

The __set( ) method takes two arguments: the property name and the new value. Otherwise, the logic inside the method is similar to __get( ).

Besides reducing the number of methods in your classes, these magical methods also make it easy to implement a centralized set of input and output validation.

Additionally, Example 7-32 shows how you can also enforce exactly what properties are legal and illegal for a given class.

Enforcing property access using magic accessor methods

class Person {     // list person and email as valid properties     protected $__data = array('person', 'email');     public function __get($property) {         if (isset($this->__data[$property])) {             return $this->__data[$property];         } else {             return false;         }     }     // enforce the restriction of only setting     // pre-defined properties     public function __set($property, $value) {         if (isset($this->__data[$property])) {             return $this->__data[$property] = $value;         } else {             return false;         }     } }

In this updated version of the code, you explicitly list the object's valid properties names when you define the $__data property. Then, inside __set( ), you use isset( ) to confirm that all property writes are going to allowable names.

Preventing rogue reads and writes is why the visibility of the $__data property isn't public, but protected. Otherwise, someone could do this:

$person = new Person; $person->__data['fake_property'] = 'fake_data';

because the magical accessors aren't used for existing properties.

Pay attention to this important implementation detail. In particular, if you're expecting people to extend the class, they could introduce a property that conflicts with a property you're expecting to handle using __get( ) and __set( ). For that reason, the property in Example 7-32 is called $__data with two leading underscores.

You should consider prefixing all your "actual" properties in classes where you use magical accessors to prevent collisions between properties that should be handled using normal methods and ones that should be routed through __get( ) and __set( ).

There are three downsides to using __get( ) and __set( ). First, these methods only catch missing properties. If you define a property for your class, __get( ) and __set( ) are not invoked by PHP when that property is accessed.

This is the case even if the property you're trying to access isn't visible in the current scope (for instance, when you're reading a property that exists in the class but isn't accessible to you, because it's declared private). Doing this causes PHP to emit a fatal error:

PHP Fatal error:  Cannot access private property...

Second, these methods completely destroy any notion of property inheritance. If a parent object has a __get( ) method and you implement your own version of __get( ) in the child, your object won't function correctly because the parent's __get( ) method is never called.

You can work around this by calling parent::__get( ), but it is something you need to explicitly manage instead of "getting for free" as part of OO design.

The illusion is incomplete because it doesn't extend to the isset( ) and unset( ) methods. For instance, if you try to check if an overloaded property isset( ), you will not get an accurate answer, as PHP doesn't know to invoke __get( ).

You can fix this by implementing your own version of these methods in the class, called __isset( ) and __unset( ), shown in Example 7-33.

Implementing magic methods for isset( ) and unset( )

class Person {     // list person and email as valid properties     protected $data = array('person', 'email');     public function __get($property) {         if (isset($this->data[$property])) {             return $this->data[$property];         } else {             return false;         }     }     // enforce the restriction of only setting     // pre-defined properties     public function __set($property, $value) {         if (isset($this->data[$property])) {             return $this->data[$property] = $value;         } else {             return false;         }     }     public function __isset($property) {         if (isset($this->data[$property])) {             return true;         } else {             return false;     }     public function __unset($property) {         if (isset($this->data[$property])) {             return unset($this->data[$property]);         } else {             return false;         }     } }

The __isset( ) method checks inside the $data element and returns true or false depending on the status of the property you're checking.

Likewise, __unset( ) passes back the value of unset( ) applied to the "real" property, or false if it's not set.

Implementing these two methods isn't required when using __get( ) and __set( ), but it's best to do so as it's hard to predict how you may use object properties. Failing to code these methods will lead to confusion when someone (perhaps even yourself) doesn't know (or forgets) that this class is using magic accessor methods.

However, the __isset( ) and __unset( ) methods are only available as of PHP 5.1.

Other reasons to consider not using magical accessors are:

  • They're relatively slow. They're both slower than direct property access and explicitly writing accessor methods for all your properties.

  • They make it impossible for the Reflection classes and tools such as phpDocumentor to automatically document your code.

  • You cannot use them with static properties.

7.11.4. See Also

Documentation on magic methods found at

PHP Cookbook, 2nd Edition
PHP Cookbook: Solutions and Examples for PHP Programmers
ISBN: 0596101015
EAN: 2147483647
Year: 2006
Pages: 445

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: