Let's take a quick look at the previous approach presented to implement our form generator, as it was initially conceived, so that we can reorder the concepts and try to fix it up. Here's the original code:
// include required class file
require_once('formclasses.php');
// instantiate derived inputText objects from super class formObject
$textField1=&new inputTextObject('First Name','firstname','textinput','',30);
$textField2=&new inputTextObject('Last Name','lastname','textinput','',30);
// instantiate derived checkbox object from super class formObject
$checkboxField=&new checkBoxObject('I want to receive the weekly newsletter.','newsletter','checkbox','newsletter');
// instantiate derived submit object from super class formObject
$submitButton=&new submitObject('','send','submitbutton','Send Data');
// make objects array
$objects=array($textField1,$textField2,$checkboxField,$submitButton);
// generate form determining what type of object is treated
foreach($objects as $object){
switch (get_class($object)){
case "inputtextobject":
echo $object->label.'<input name="'.$object->name.'" type="text" maxlength="'.$object->maxlength.'" /><br />';
break;
case "checkboxobject":
echo '<input name="'.$object->name.'" type="checkbox" value="'.$object->value.'" />'.$object->label.'<br />';
break;
case "radiobuttonobject":
echo '<input name="'.$object->name.'" type="radio" value="'.$object->value.'" />'.$object->label.'<br />';
break;
case "submitobject":
echo $object->label.'<input name="'.$object->name.'" type="submit" value="'.$object->value.'" /><br />';
break;
default:
break;
}
}
As you can see, the above method generates the HTML form in a very inefficient way, since is employing a "switch" statement to evaluate what type of form element is being processed, and displaying the corresponding HTML markup. At the risk of being repetitive, there are some key issues that need to be explained here. First, we're accessing properties of the form elements directly. That's definitely a bad coding practice. Always use the interface of the object to access its properties. Doing so, we're applying correctly the other pillar of OOP: Encapsulation.
Even more, since PHP 4 doesn't offer a method to declare class properties to be either public or private, the PHP parser won't complain at all, since each property is by default publicly accessible. However, it's not recommended to access properties directly. In PHP 5, where you can declare properties and methods as being public or private (a definitively desirable improvement), any properties or methods defined as private but accessed directly will trigger an error.
The second issue to be addressed is maintenance. If we need to add one or more form elements to the script, the updating process is really painful and completely impractical. Just imagine adding a "case" statement for each form element added. It's even worse if we need to implement many forms on our website, as usually happens in several projects. That will be a real updating nightmare. Definitely, this approach doesn't require any further analysis.
By this point, we need to find another solution for implementing the form generator in an efficient way. However, all is not lost. This article's title references Polymorphism in PHP, right? Let's have a look at its core definition and practical implementation. Trust me, it's really fun!
