After going through single and double dispatch, it’s time to shift gears to the next major feature of the Visitor pattern; the Traverser. One of the most important (and often omitted) components of the Visitor design pattern is the Object Structure. In Part II the focus is on the double-dispatch, the number of elements that could be visited at once. The Object Structure is set up to collect the allowable visitors to visit the elements; however, only one element at at time can be displayed because the middle of the the foreach loop in the confirm() method contains a return statement—so as soon a the iteration begins, it ends with the return statement. (Let’s face it; it’s a pseudo-transveral.) Since Part II focuses on the double-dispatch, the number of elements that could be visited at one time is a tangental issue. This post, though, focuses squarely on the traversal process and the multiple elements that can be visited in a single process.
Updating the Visitor
In order to have all of the parts merrily humming along, a few changes are in order. Importantly, once these changes are made, all of the parts are still working and interacting together. To see what’s changed but how the structure is basically the same as the visitor in Part II focuses on the double-dispatch, the number of elements that could be visited at on, download the new set of files and test the new multiple element visitor:
Right away, you will see that instead of radio buttons, the HTML5 UI uses check boxes for selecting one, two or three elements and then applies the visitors one at a time.(You can supply your own error-handling routine for selecting no elements!)
The HTML Element Array
One of the nicest attributes in HTML is the ability to treat a group of checkboxes with “element values” (elements as elements in an array). Each checkbox is given a name with empty brackets (e.g., my element[]). All of the selected (checked) checkboxes with the identical element name are automatically included in an array with the element name. You don’t have to worry about the unchecked ones as they are not included in the array passed to PHP.
|
That checkbox array feature made it very easy to pass the shape class names (as strings) to the Client.
The Updated Client
The Client class is changed slightly to accept an array of shapes rather than just one as was done in Parts I and II of the Visitor series. Likewise, some steps were tightened up in the ObjectStructure class for cleaning up the traversal process.
//Client.php
error_reporting(E_ALL | E_STRICT);
ini_set("display_errors", 1);
// Autoload given function name.
function includeAll($className)
{
include_once($className . '.php');
}
//Register
spl_autoload_register('includeAll');
class Client
{
private static $shapeElement;
private static $color;
private static $package;
//client request
public static function request()
{
self::$shapeElement= array();
self::$shapeElement=$_POST['shape'];
self::$color=$_POST['color'];
self::$package= array();
$obStructure = new ObjectStructure();
$colorVisitor= new self::$color();
//Attach concrete elements to array & accept visitor
foreach (self::$shapeElement as $shapeNow)
{
$obStructure->attach(new $shapeNow,$colorVisitor);
}
//Display selected shapes
self::$package=$obStructure->getElements();
foreach (self::$package as $colorShape)
{
echo $colorShape->showShape();
}
}
}
Client::request();
?>
|
The Client calls on the traversal process using an instance of the OjbectStructure. The attach() method now has two parameters; a shape and a color. The shape is passed as a shape element generated by the foreach loop, creating a new shape with each iteration while adding the same color visitor to all shapes. Once everything has been stored in the ObjectStructure, a second loop calls the getElements() methods, which returns shapes with the appropriate color visitor.
The ObjectStructure
The ObjectStructure class is small but mighty. The Gang of Four note,
A client that uses the Visitor pattern must create a ConcreteVisitor object and then traverse the object structure, visiting each element with the visitor.
Several choices are available to transverse the elements from the client through the object structure, but as seen, the humble (yet mighty) foreach loop handles the job elegantly and efficiently. The OjbectStructure provides the methods the client uses for traversal.
//ObjectStructure.php
class ObjectStructure
{
private $elements=array();
public function attach(IElement $element,IVisitor $colorVis)
{
$element->accept($colorVis);
array_push($this->elements,$element);
}
public function getElements()
{
return $this->elements;
}
}
?>
|
In Part II of the Visitor series, the attach() method only served to push the element onto an array, but here the method, now with two instead of one parameter serves double duty. First, each shape accepts (using the IElement::accept() method) the visitor. Second, each shape is added to an array, $elements. In some respects, this acts like a setter operation.
The only other method, getElements() returns the shapes with the accepted color. The client can then display them on the screen.
Minor Adjustments
In order to expand the screen size for multiple objects to be displayed, a few other adjustments were necessary as well. However, very few were required. All of the new settings for each shape, that have been staggered vertically and horizontally, are simple ones, and most were made in the IElement interface. Also, the Zigzag concrete element is removed and a new color visitor, BurntOrange has been added. The following listing shows representatives from each participant and the shape interface.
//IElement.php
interface IElement
{
const SVG =";
function accept(IVisitor $visitor);
}
?>
//Circle.php
class Circle implements IElement
{
private $visColor;
public function accept(IVisitor $visitor)
{
$visitor->visitCircle($this);
}
public function showShape()
{
$circleShape= IElement::SVG . "
|
The important aspect of this process to note is that all of the different parts interacted and functioned together after the changes. By focusing on the interfaces and knowing the different roles of the participants, keeping the 11 different PHP files along with the HTML and CSS files coordinated is not that difficult. The added BurntOrange class required only a change in the HTML to include it. None of the other classes had to be altered.
The Practical Visitor
All of the examples in this Visitor series have been designed to reveal 1) The separation of an object from an operation, 2) how to add an operation to an existing object and 3) how to create new operations that that be integrated into an object structure so that several objects can use the same operation. Each of the shapes represent the implementation of a concrete element, and each color, a visiting operation that can be added to the elements in the object structure. A well structured composite program adds flexibility to anything that changes; and in today’s environment, change is constant.
Programming structures should not be delicate flowers that will wither and die at the first sign of change. If that is the case with your programs; you may want to think about creating stronger structures that not only can withstand change but be structured to invite change and improvement. The Visitor is one such design pattern. As always, I appreciate any comments or ideas you may have or innovative implementations of the Visitor.
Copyright © 2015 William Sanders. All Rights Reserved.
0 Responses to “PHP Visitor Design Pattern III: Traverser”