Compare the following examples, the first using PHP’s default copying behavior:

<?php      
$color = 'blue';      
$settings['color'] = $color; // Makes a copy      
$color = 'red'; // $color changes      
echo $settings['color']; // Displays "blue"      
?>

The second involves passing by reference:

<?php      
$color = 'blue';      
$settings['color'] = &$color; // Makes a reference      
$color = 'red'; // $color changes      
echo $settings['color']; // Displays "red"      
?>

Passing by reference allows us to keep the new variable “linked” to the original source variable. Changes to either the new variable or the old variable will be reflected in the value of both.

So far, so good. You’re probably wondering, “What’s the big deal here? What difference does it make whether PHP copies or makes a reference to a variable, as long as we get what we expected?” For variables passed around a procedural program, you hardly ever need to worry about references. However, when it comes to objects interacting with one another, if you don’t pass an object by reference, you may well get results you weren’t expecting.

The Importance of References

Imagine you have a mechanism on your site that allows visitors to change the look and feel of the site—a user “control panel.” It’s likely that, to implement this sort of functionality, you’d have code that acts on a set of variables containing “look and feel” data, to modify them independently of the rest of the application’s logic.

Representing this simply with classes, first, let’s see the class that will store data-related to look and feel:

Example 2.8. 5.php (excerpt)

<?php      
// Look and feel contains $color and $size      
class LookAndFeel {      
 var $color;      
 var $size;      
 function LookAndFeel()      
 {      
   $this->color = 'white';      
   $this->size = 'medium';      
 }      
 function getColor()      
 {      
   return $this->color;      
 }      
 function getSize()      
 {      
   return $this->size;      
 }      
 function setColor($color)      
 {      
   $this->color = $color;      
 }      
 function setSize($size)      
 {      
   $this->size = $size;      
 }      
}

Next, we have a class that deals with rendering output:

Example 2.9. 5.php (excerpt)

// Output deals with building content for display      
class Output {      
 var $lookandfeel;      
 var $output;      
     
 // Constructor takes LookAndFeel as its argument      
 function Output($lookandfeel)      
 {      
   $this->lookandfeel = $lookandfeel;      
 }      
 function buildOutput()      
 {      
   $this->output = 'Color is ' . $this->lookandfeel->getColor() .      
     ' and size is ' . $this->lookandfeel->getSize();      
 }      
 function display()      
 {      
   $this->buildOutput();      
   return $this->output;      
 }      
}

Notice the constructor for the Output class. It takes an instance of LookAndFeel as its argument so that, later, it can use this to help build the output for the page. We’ll talk more about the ways classes interact with each other later in this chapter.

Here’s how we use the classes:

Example 2.10. 5.php (excerpt)

// Create an instance of LookAndFeel      
$lookandfeel = new LookAndFeel();      
     
// Pass it to an instance of Output      
$output = new Output($lookandfeel);      
     
// Display the output      
echo $output->display();      
?>

This displays the following message:

Color is white and size is medium

Now, let’s say that, in response to one of the options on your user control panel, you want to make some changes to the look and feel of the site. Let’s put this into action:

Example 2.11. 6.php (excerpt)

$lookandfeel = new LookAndFeel(); // Create a LookAndFeel      
$output = new Output($lookandfeel); // Pass it to an Output      
     
// Modify some settings      
$lookandfeel->setColor('red');      
$lookandfeel->setSize('large');      
     
// Display the output      
echo $output->display();

Using the setColor and setSize methods, we change the color to “red” and the size to “large,” right? Well, in fact, no. The output display still says:

Color is white and size is medium

Why is that? The problem is that we’ve only passed a copy of the LookAndFeel object to $output. So the changes we make to $lookandfeel have no effect on the copy that $output uses to generate the display.

To fix this we have to modify the Output class so that it uses a reference to the LookAndFeel object it is given. We do this by altering the constructor:

Example 2.12. 7.php (excerpt)

 function Output(&$lookandfeel)      
 {      
   $this->lookandfeel = &$lookandfeel;      
 }

Notice that we have to use the reference operation twice here. This is because the variable is being passed twice—first to the constructor function, then again, to place it in a member variable.

Once we’ve made these changes, the display looks like this:

Color is red and size is large

In summary, passing by reference keeps the target variable “linked” to the source variable, so that if one changes, so does the other.

Good and Bad Practices

When working with classes and objects, it’s a good idea to use references whenever an object is involved. Occasionally, you may have to do the same with an array, such as when you want to sort the array in a different section of code. But, for the most part, normal variables will not need this treatment, simply because, when your code reaches the level of complexity where you’d need to do so, you will (I hope!) be storing variables inside objects and passing the complete object by reference.

Let’s look at some other situations in which you might need to use references…

// Make sure $myObject is a reference to      
// the variable created by the new keyword      
$myObject = &new MyClass();

This looks odd at first, but remember, a variable created by the new keyword is being passed here—even if you can’t see it. The reference operator saves PHP from having to create a copy of the newly-created object to store in $myObject.

class Bar {      
}      
     
class Foo {      
 // Return by reference      
 function &getBar()      
 {      
   return new Bar();      
 }      
}      
     
// Instantiate Foo      
$foo = &new Foo();      
     
// Get an instance of Bar from Foo      
$bar = &$foo->getBar();

In the above example, you’ll notice the getBar method in the Foo class. By preceding the function name with the reference operator, the value the function returns is passed by reference. Note that we also had to use a reference operator when assigning the return value of getBar to $bar. This technique is commonly used when a class method will return objects.

What’s bad practice is the following:

function display($message) {      
 echo $message;      
}      
     
$myMessage = 'Hello World!';      
     
// Call time pass by reference - bad practice!      
display(&$message);

That’s known as a call-time pass-by-reference, which PHP controls with the following setting in php.ini:

allow_call_time_pass_reference = Off

By default, in recent PHP releases the above setting should be switched to Off; turning it on is “frowned upon” by PHP’s makers. Switched off, PHP will generate warning errors every time a function call specifies an argument should be passed by reference. As such, it’s good practice to leave this setting off.

The reason why call time pass by reference is a “bad thing” is that call time passing by reference can make code extremely difficult to follow. I’ve occasionally seen PHP XML parsers written using a call-time pass-by-reference—it’s nearly impossible to gain any idea of what’s going on.

The “decision” as to whether a variable is passed by reference or not is one that belongs to the function being called, not the code that calls it. The above code written correctly would look like this:

// Accept by reference - good practice      
function display(&$message)      
{      
 echo $message;      
}      
     
$myMessage = 'Hello World!';      
     
display($message);

Performance Issues

Depending on the scale of your application, there are some performance issues you might need to consider when using references.

In simple cases of copying one variable to another PHP's internal reference counting feature prevents unnecessary memory usage. For example,

$a = 'the quick brown fox';      
$b = $a;

In the above example, the value of $b would not take up any extra memory, as PHP’s internal reference counting will implicitly reference $b and $a to the same location in memory, until their values become different. This is an internal feature of PHP and affects performance without affecting behavior. We don’t need to worry about it much.

In some cases, however, using a reference is faster, especially with large arrays and objects, where PHP's internal reference counting can’t be used. and the contents must therefore be copied.

So, for best performance, you should do the following:

• With simple values such as integers and strings, avoid references whenever possible.
• With complex values such as arrays and objects, use references whenever possible.

References and PHP 5

With PHP 5, references will cease to be an issue because the default behavior of PHP, when passing objects, will be to pass by reference. If you ever need a copy of an object, you can use the special __clone method to create copies.

Essentially, the change brings PHP in line with the majority of object oriented programming languages like Java, and will certainly do a lot to reduce the confusion surrounding the subject. For now, though, and until PHP 5 has been widely adopted, knowing how references work is important.

How do I take advantage of inheritance?

Inheritance is one of the fundamental pieces of the object oriented paradigm and is an important part of its power. Inheritance is a relationship between different classes in which one class is defined as being a child or subclass of another. The child inherits the methods and member variables defined in the parent class, allowing it to “add value” to the parent.

The easiest way to see how inheritance works in PHP is by example. Let’s say we have this simple class:

Example 2.13. 8.php (excerpt)

<?php        
class Hello {        
 function sayHello()        
 {        
   return 'Hello World!';        
 }        
}

Using the extends keyword, we can make a class that’s a child of Hello:

Example 2.14. 8.php (excerpt)

class Goodbye extends Hello {        
 function sayGoodbye()        
 {        
   return 'Goodbye World!';        
 }        
}

Goodbye is now a child of Hello. Expressed the other way around, Hello is the parent or superclass of Goodbye. Now, we can simply instantiate the child class and have access to the sayHello and the sayGoodbye methods using a single object:

Example 2.15. 8.php (excerpt)

$msg = &new Goodbye();        
       
echo $msg->sayHello() . '<br />';        
echo $msg->sayGoodbye() . '<br />';        
?>

That example shows the basics of how inheritance works, but doesn’t demonstrate its real power… This comes with the addition of overriding.

Overriding

What happens when we give a function in the child the same name as a function in the parent? An example:

Example 2.16. 9.php (excerpt)

<?php        
class Hello {        
 function getMessage()        
 {        
   return 'Hello World!';        
 }        
}        
       
class Goodbye extends Hello {        
 function getMessage()        
 {        
   return 'Goodbye World!';        
 }        
}

Both classes have the same method name, getMethod. This is perfectly acceptable to PHP—it makes no complaints about a method being declared twice.

Here’s what happens when we use the classes:

Example 2.17. 9.php (excerpt)

$hello = &new Hello();        
echo $hello->getMessage() . '<br />';        
       
$goodbye = &new Goodbye();        
echo $goodbye->getMessage() . '<br />';        
?>

And the output is as follows:

Hello World!        
Goodbye World!

Calling getMessage via the $goodbye object displays “Goodbye World!” The method in the child class is overrides the method in the parent class.

You can also have the child class make use of the parent class’s method internally, while overriding it. For example:

Example 2.18. 10.php

<?php        
class Hello {        
 function getMessage()        
 {        
   return 'Hello World!';        
 }        
}        
       
class Goodbye extends Hello {        
 function getMessage()        
 {        
   $parentMsg = parent::getMessage();        
   return $parentMsg . '<br />Goodbye World!';        
 }        
}        
       
$goodbye = &new Goodbye();        
echo $goodbye->getMessage() .'<br />';        
?>

Using the parent keyword, we can call the parent class’s method.

Note that we can also call the parent class by name to achieve exactly the same result:

class Goodbye extends Hello {        
 function getMessage() {        
   $parentMsg = Hello::getMessage();        
   return $parentMsg . '<br />Goodbye World!';        
 }        
}

Notice that we’ve replaced the parent keyword with the name of the Hello class. The output is exactly the same. Using parent, however, saves you from having to remember the name of the parent class while working in the child, and is the recommended syntax.

A call such as parent::getMessage() or Hello::getMessage() from a non-static method is not the same as calling a static function. This is a special case where inheritance is concerned. The called function in the parent class retains access to the instance data, and is therefore not static. This may be demonstrated as follows:

Example 2.19. 11.php

<?php        
class A {        
   var $a = 1;        
   function printA()        
   {        
       echo $this->a;        
   }        
}        
       
class B extends A {        
   var $a = 2;        
   function printA()        
   {        
      parent::printA();        
      echo "\nWasn't that great?";        
   }        
}        
       
$b = new B();        
$b->printA();        
?>

The output generated from the above is as follows:

2

Wasn't that great?

PHP does not cascade constructors

If you create a constructor in a child class, be aware that you are completely overriding the parent class’s constructor, and that you must call it explicitly from your new constructor if you still want the parent class to handle its share of the object initialization.

Overriding declared member variables is achieved in exactly the same way as methods, although you’re unlikely to use this feature frequently.

Inheritance in Action

Now that you have a rough idea of how inheritance is used in PHP, it’s time to look at an example that should give you a better idea of how inheritance can be applied.

The following example implements a simple navigation system for a Web page, generating the HTML that appears at the top of the page. By having one class inherit from another, it becomes possible to add “crumb trail” navigation to the page when it’s needed.

First up, the StandardHeader class deals with generating the HTML for the top of the page, as well as supplying the setHeader and getHeader methods to access the variable where the HTML is stored.

Example 2.20. 12.php (excerpt)

<?php        
/**        
* A standard header for a Web page        
*/        
class StandardHeader {        
 /**        
  * The header HTML is stored here        
  */        
 var $header = '';        
       
 /**        
  * The constructor, taking the name of the page        
  */        
 function StandardHeader($title)        
 {        
   $html = <<<EOD        
<html>        
<head>        
<title> $title </title>        
</head>        
<body>        
<h1>$title</h1>        
EOD;        
   $this->setHeader($html);        
 }        
       
 /**        
  * General method for adding to the header        
  */        
 function setHeader($string)        
 {        
   if (!empty($this->header)) {        
     $this->header .= $string;        
   } else {        
     $this->header = $string;        
   }        
 }        
       
 /**        
  * Fetch the header        
  */        
 function getHeader()        
 {        
   return $this->header;        
 }        
}

Now, the subclass CategoryHeader brings extra functionality to its parent, adding the “bread crumb” links to the HTML that was generated. We don’t need to recreate the setHeader and getHeader methods, as these are inherited from StandardHeader when CategoryHeader is instantiated.

Example 2.21. 12.php (excerpt)

/**        
* Subclass for dealing with Categories, building a breadcrumb        
* menu        
*/        
class CategoryHeader extends StandardHeader {        
 /**        
  * Constructor, taking the category name and the pages base URL        
  */        
 function CategoryHeader($category, $baseUrl)        
 {        
   // Call the parent constructor        
   parent::StandardHeader($category);        
       
   // Build the breadcrumbs        
   $html = <<<EOD        
<p><a href="$baseUrl">Home</a> >        
<a href="$baseUrl?category=$category">$category</a></p>        
EOD;        
   // Call the parent setHeader() method        
   $this->setHeader($html);        
 }        
}

Let’s now put these two classes to use:

Example 2.22. 12.php (excerpt)        
       
// Set the base URL        
$baseUrl = '12.php';        
       
// An array of valid categories        
$categories = array('PHP', 'MySQL', 'CSS');        
       
// Check to see if we're viewing a valid category        
if (isset($_GET['category']) &&        
   in_array($_GET['category'], $categories)) {        
       
 // Instantiate the subclass        
 $header = new CategoryHeader($_GET['category'], $baseUrl);        
} else {        
       
 // Otherwise it's the home page. Instantiate the Parent class        
 $header = new StandardHeader('Home');        
}        
       
// Display the header        
echo $header->getHeader();        
?>        
<h2>Categories</h2>        
<p><a href="<?php echo $baseUrl; ?>?category=PHP">PHP</a></p>        
<p><a href="<?php echo $baseUrl; ?>?category=MySQL">MySQL</a></p>        
<p><a href="<?php echo $baseUrl; ?>?category=CSS">CSS</a></p>        
</body>        
</html>

As you can see, the controlling logic above looks for a $_GET['category'] variable. If it exists, it creates an instance of CategoryHeader, displaying the navigation to allow users to find their way back to the home page. But if it doesn’t exist, it creates an instance of the parent StandardHeader instead, which applies when users view the home page (and therefore does not require bread crumbs to find their way back).

In other words, inheritance allows us to add the extra functionality we need without having to reproduce the logic that already resides within the parent class; the existing methods and logic can be reused via the child subclass.

Inheritance provides a powerful mechanism to make classes that are modular, addressing a specific problem, while still making available shared methods and variables that can be used irrespective of the specific object we’re dealing with.

Avoid Deep Inheritance Structures

Doing so is often a sign of a bad design, in which opportunities for classes to interact in different ways (see the next solution) were missed. In practice, having more than two generations of classes often leads to all sorts of debugging problems and makes the code difficult to maintain. For example, it can become hard to keep track of variable names you’ve used higher up in the hierarchy.

How do objects interact?

Aside from inheritance, there are other ways for objects to interact; for example, one object uses another object. In many ways, such interactions are more important than inheritance, and this is where the object oriented paradigm shows its real power.

There are two ways in which one object can use another: aggregation and composition.

Aggregation

Aggregation occurs when one object is given another object on “temporary loan.” The second object will usually be passed to the first through one of the first’s member functions. The first object is then able to call methods in the second, allowing it to use the functionality stored in the second object for its own purposes.

A common example of aggregation in action involves a database connection class. Imagine you pass a database connection class to some other class, which then uses the database connection class to perform a query. The class performing the query aggregates the database connection class.

Here’s a simple example using the MySQL class, which we’ll create in Chapter 3, PHP and MySQL:

Example 2.23. 13.php

<?php          
// Include the MySQL database connection class          
require_once 'Database/MySQL.php';          
         
// A class which aggregates the MySQL class          
class Articles {          
 var $db;          
 var $result;          
 // Accept an instance of the MySQL class          
 function Articles(&$db)          
 {          
   // Assign the object to a local member variable          
   $this->db = &$db;          
   $this->readArticles();          
 }          
 function readArticles()          
 {          
   // Perform a query using the MySQL class          
   $sql = "SELECT * FROM articles LIMIT 0,5";          
   $this->result = &$this->db->query($sql);          
 }          
 function fetch()          
 {          
   return $this->result->fetch();          
 }          
}          
         
// Create an instance of the MySQL class          
$db = &new MySQL('localhost', 'harryf', 'secret', 'sitepoint');          
         
// Create an instance of the Article class, passing it the MySQL          
// object          
$articles = &new Articles($db);          
         
while ($row = $articles->fetch()) {          
 echo '<pre>';          
 print_r($row);          
 echo '</pre>';          
}          
?>

In the above example, we instantiate the MySQL class outside the Articles class, then pass it to the Articles constructor as Articles is instantiated. Articles is then able to use the MySQL object to perform a specific query. In this case, Articles aggregates the MySQL object. Figure 2.2 illustrates this relationship with UML.

Figure 2.2. Aggregation

Composition

Composition occurs when one object “completely owns” another object. That is, the first object was responsible for creating (instantiating) the second object. There are many cases in which this can be useful, although, typically, composition is used when it’s likely that the first object will be the only one that needs to use the second object.

One example from Chapter 1, Access Control is the Auth class, which composes an instance of the Session class, creating it in the constructor:

class Auth {          
 …          
         
 /**          
  * Instance of Session class          
  * @var Session          
  */          
 var $session;          
         
 …          
         
 function Auth (&$dbConn, $redirect, $md5 = true)          
 {          
   $this->dbConn = &$dbConn;          
   $this->redirect = $redirect;          
   $this->md5 = $md5;          
   $this->session = &new Session();          
   $this->checkAddress();          
   $this->login();          
 }

Because the Auth class needs to read and write to session variables, and only a limited number of other, unrelated classes in an application are likely also to need to use Session, it’s logical that it gets to create its own Session object.

Figure 2.3 illustrates the composition in this example with UML.

Figure 2.3. Composition

Spotting the Difference

The general “thought test” to spot whether object A aggregates or composes object B is to ask, “What happens if object A dies? Will object B still be alive?” If object B outlives the death of object A, object A is said to aggregate object B. But if object B dies when object A dies, then object A is said to compose object B.

In terms of practical development, knowing when to apply aggregation or composition is important.

Aggregation has the advantage of lower overhead, because a single object will be shared by many other objects. Certainly, aggregating your database connection class is a good idea; composing it with every object that wants to make a query may require you to have multiple connections to your database, which will quickly halt your application when your site attracts high levels of traffic.

Composition has the advantage of making classes easier to work with from the outside. The code that uses the class doesn’t have to worry about passing it the other objects it needs, which, in a complex application, can often become tricky and result in a design “work around.” Composition also has the advantage that you know exactly which class has access to the composed object. With aggregation, another object sharing the aggregated object may do something to its state that “breaks” the object as far as the other classes that use it are concerned.

Polymorphism

Another powerful aspect of object oriented programming is polymorphism—the ability of different classes to share an interface.

An interface is one or more methods that let you use a class for a particular purpose. For example, you could have two database connection classes—one for MySQL and one for PostgreSQL. As long as they both offered a query method, you could use them interchangeably for running queries on different databases. The query method is a simple interface that the two classes share.

The classes sharing the same interface are often inherited from a parent class that makes the common methods available. Again, this is best understood by example.

First, we define an abstract base class, Message, which provides the common method getMessage. Beneath the Message class, we define concrete classes, each of which creates a specific message.

The terms “abstract” and “concrete” refer to class usage, in particular, whether a class is intended to be used directly or not. An abstract class is one in which some functionality or structure is to be shared by all subclasses, but is not intended to be used directly; typically, it has one or more empty methods that don’t do anything useful. In other words, you’re not supposed to create objects from an abstract class. A concrete class is a subclass of the abstract class from which you can create objects. Some languages, like Java, provide support for abstract classes within the language syntax—something PHP 4 doesn’t offer. You can still use the concept of abstract classes when designing applications, though you might consider adding documentation to tell other developers working with the code that the class is abstract.

Example 2.24. 14.php (excerpt)

<?php          
class Message {          
 var $message;          
 function setMessage($message)          
 {          
   $this->message = $message;          
 }          
 function getMessage()          
 {          
   return $this->message;          
 }          
}          
class PoliteMessage extends Message {          
 function PoliteMessage()          
 {          
   $this->setMessage('How are you today?');          
 }          
}          
         
class TerseMessage extends Message {          
 function TerseMessage()          
 {          
   $this->setMessage('Howzit?');          
 }          
}          
         
class RudeMessage extends Message {          
 function RudeMessage()          
 {          
   $this->setMessage('You look like *%&* today!');          
 }          
}

Now, we define the MessageReader class, which takes an array of Message objects through its constructor.

Example 2.25. 14.php (excerpt)

class MessageReader {          
 var $messages;          
 function MessageReader(&$messages) {          
   $this->messages = &$messages;          
   $this->readMessages();          
 }          
 function readMessages() {          
   foreach ($this->messages as $message) {          
     echo $message->getMessage() . '<br />';          
   }          
 }          
}

The important thing to note here is that, as far as MessageReader is concerned, a “Message object” is any object that was instantiated from the Message class or one of its subclasses. Did you see how, inside the readMessages method, we call the getMessage method? This code will work on any object that has a getMessage method—including any subclass of Message.

Now, to prove the point, let’s create some Message objects using our three subclasses at random:

Example 2.26. 14.php (excerpt)

$classNames =          
 array('PoliteMessage', 'TerseMessage', 'RudeMessage');          
$messages = array();          
srand((float)microtime() * 1000000); // Prepares random shuffle          
for ($i = 0; $i < 10; $i++) {          
 shuffle($classNames);          
 $messages[] = new $classNames[0]();          
}          
$messageReader = new MessageReader($messages);          
?>

By creating the array $classNames and then repeatedly shuffling it, we can take the first element of the array and use it to create a new object:

 $messages[] = new $classNames[0]();

This is an example of a variable function. The expression $classNames[0] is evaluated to determine the name of the constructor (PoliteMessage, TerseMessage, or RudeMessage) to call.

Finally, the $messages array contains ten messages, randomly selected, and is passed to the constructor of MessageReader on instantiation.

Here’s a sample result:

You look like *%&* today!          
Howzit?          
How are you today?          
How are you today?          
How are you today?          
You look like *%&* today!          
How are you today?          
How are you today?          
Howzit?          
How are you today?

Each time we execute the script, the list is different.

Because all the concrete message classes share the same getMethod function (i.e. they implement the same interface), the MessageReader class is able to extract the data without knowing which particular type of message it’s dealing with. The ability for a group of related classes to work interchangeably is called polymorphism, and is illustrated in the UML diagram in Figure 2.4.

Figure 2.4. Polymorphism

This aspect of object oriented programming can be very powerful once you realize its worth. You might have a collection of objects representing HTML tags, for example, each being a subclass of a parent HTMLTag class, from which they all inherit a render method. Another class that handles the rendering of a page could take a collection of HTMLTag objects and create the page by calling each object’s render method.

Further Reading

• Object Oriented PHP: Paging Result Sets http://www.sitepoint.com/article/662 [6]
• PHP References Explained http://www.zez.org/article/articleview/77/ [7]
• PHP References Part 1: http://www.onlamp.com/pub/a/php/2002/08/15/php_foundations.html [8] Part 2: http://www.onlamp.com/pub/a/php/2002/09/12/php_foundations.html [9]
• PHP Reference Counting and Aliasing http://www.zend.com/zend/art/ref-count.php [10]

Look out for more chapters from The PHP Anthology on SitePoint in coming weeks! If you can't wait, download the sample chapters [11], or order your very own copy now [12]!