Late Binding in PHP 5, or, the Lack Thereof - PHP

In my opinion, late binding is what makes Java and C# so spectacular. They allow base class methods to invoke methods in “this”, or $this, even if they do not exist in the base class--or, better yet, to invoke a method from the base class that may be replaced by another version in an inherited class. You may think something like this would work in PHP:

<?php

class Person
{
            function AddFeedback($messageArray)
            {
                        $this->ParseFeedback($messageArray);
                        // Write to database
            }
}

class David extends Person
{
            function ParseFeedback($messageArray)
            {
                        // Do some parsing                   
            }
}
?>

Keep in mind that there is no ParseFeedback in the Person class. Now, say you have this implementation code, which, for the sake of example, results in $myPerson being a David object:

<?php
$myPerson = Person::GetPerson($name);
$myPerson->AddFeedback($messageArray);
?>

PARSE ERROR! The method ParseFeedback does not exist, or something along those lines. Sigh! So much for late binding in PHP 5! Wait--you probably want to know what late binding is.

Late binding means that method invocations bind to the target object at the last possible minute, which means those objects already have a concrete type when the method is invoked by the runtime. In our example above, you would be calling David::AddFeedback(), and since $this in David::AddFeedback() references a David object, you would logically assume that the ParseFeedback() method exists--but it does not, because AddFeedback() was defined in Person, and calls ParseFeedback() from the Person class.

Unfortunately there is no simple way to skate around this rotten behavior in PHP 5, which means you’re somewhat neutered when it comes to creating a flexible polymorphic class heirarchy.

I must point out that I chose PHP 5 as the language for this article simply for this reason: it’s not very good for abstracting object concepts! Consider it a cautionary tale from someone who learned it the hard way, beginning with PHP 5 when it was still in alpha and assuming that since they added abstract classes and interfaces, late binding was a given.

The End

You should now have a basic understanding of polymorphism and why PHP 5 is not very good at implementing it. You should, generally speaking, know how to encapsulate conditional behavior with a polymorphic object model. Ultimately what you should gain from this is flexibility in your objects, which of course means less code overall. You may end up creating a few more class and a few more class methods, but your calling code will be greatly reduced, which almost always results in time and effort savings. You also increase the clarity of your code by encapsulating conditional behavior-–behavior based on an object’s state-–within the object itself, rather than handling it with code that, for all intents and purposes, should not know enough about the object to make any real decisions on such matters.

If, like myself, you find yourself to be passionately interested in object oriented design, read what I consider to be the three fundamentals: "Design Patterns" (ISBN: 0201633612), "Refactoring" (ISBN: 0201485672), and "Refactoring to Patterns" (ISBN: 0321213351). I would suggest reading them in the stated order. They provide a far more extensive and expert opinion than my own, and will set you on the path to good object oriented software design.