Archive for the 'Builder' Category

PHP Builder Design Pattern Part II: Iterating through an Interface

Published on November 5, 2013 by Bill Sanders in Builder and Iterating through Objects. 4 Comments Tags: , , , .

practicalBuilder250Getting the Director Right

Part I of the Builder two-part series explains the Builder pattern and provides a simple example. Back in early 2009, I had used a similar example in ActionScript 2.0 that performed a similar task; namely building different Web pages from a single Builder pattern. (If you experienced déjà vu, it may be that you came across that earlier post.) At the time I added all of the necessary participants, but I really was not too concerned with certain details because the goal focused more on getting the participants to perform their tasks correctly than on some of the details. In Part I, the PHP example paid closer attention to details, but again, the focus was on exposition more than detailed features.

Figure 1: Director details in Builder class diagram.

Figure 1: Director details in Builder class diagram.

Figure 1 shows that portion of the original Gang of Four class diagram illustrating the role of the Director. Significantly is the pseudocode notation indicating some kind of loop through an object fires off the concrete Builder parts. In Part I, the Director simply runs all of the methods attached to a concrete builder. Most of the examples that I found of the Director, ranging from PHP to Java, use the same general approach.

Upon closer examination of the examples shown in the original Design Patterns: Elements of Reusable Object-Oriented Software, I realized that two different examples illustrated the Builder. The first one is an RTF Reader and the second is based on a Maze example from an earlier chapter. I had been digging through the code in the maze example without much luck. In the pseudocode notation of the RTF Reader, however, it shows a while loop used in conjunction with a switch statement. I tried writing similar code in PHP, and it worked like a champ, but it was not very reusable. (I rarely imply that GoF might have done something less than perfect!) So I went to work using the more abstract pseudocode notation in the structural class diagram. However, before getting into that, go ahead and test the application with the Play buttons and download all of the code.
PlayAPlayBDownload

Iterating Through an Object in PHP

All I needed to do was to create a simple loop that would iterate through an object. Originally, I thought that I’d need to use an object created by implementing a concrete Builder. However, in looking closely at the Builder class diagram, you can see that the Builder interface does not include a getResult() method. That method is only in the concrete Builder to get the assembled Product. Also, I found that I got a constructor function (__construct()) if I used a concrete Builder as a target object. So why not use the interface as the object? Figure 2 shows the general method for finding the methods in a class, and it works for interfaces as well.

Figure 2: Getting methods from classes and interfaces

Figure 2: Getting methods from classes and interfaces

So far so good. Now I have an object with all of the method names in string format. As you may know, PHP allows you to use strings to create variables, but you can also dynamically generate usable methods using variable functions. Figure 3 shows the format with an example of how to do it with a string stored in a PHP variable.

Figure 3: Using a string value to call a class method

Figure 3: Using a string value to call a class method

The trickiest part for me was remembering to place a ‘$’ in front of the method. However, once I got used to that idea, the rest was a matter of iterating through the object containing the methods and placing them on a concrete Builder instance. As you can see in the following listing the Director class is now much more re-usable:

?View Code PHP 
< ?php
//Director.php
class Director
{
    private $builder;
    private $builder_methods;
    public function doBuild(IBuilder $buildNow)
    {
        $this->builder=$buildNow;
        $this->builder_methods=get_class_methods('IBuilder');
        foreach($this->builder_methods as $part)
        {
              $this->builder->$part();
        }
    }
}
?>

Given this format, you can use the identical Director for any PHP Builder application you might create. The only change would be the name of the interface from IBuilder to whatever name you want to use. It pulls out all of the abstract method names from the interface and then assigns then to whatever concrete Builder instance is passed to it. It does not matter how they’re implemented as long as they adhere to the structure. However, you may also create different Directors using the same Builder interface by ordering the building blocks in a different way. (More on this later.)
Continue reading ‘PHP Builder Design Pattern Part II: Iterating through an Interface’

PHP Builder Design Pattern Part I: One Process, Many Representations

Published on October 27, 2013 by Bill Sanders in Builder. 2 Comments Tags: , .

builderCover250Let’s Build Something!

A lot of the work PHP developers do involves creating the same thing with variations. For example, you may create a Web site with different organizations for desktop displays, tablet screens and mobile views. However, you want the content the same, and while set up differently, you want to have a navigation system, headers, links and all the rest that goes into a Web site. The same is true for working with MySQL, and forms of different kinds. You can create fairly complex objects, but the representations (e.g., desktop, smartphone) are different. The Builder Design pattern is a creational pattern that lets you separate the construction of complex objects from their representations so that the same construction process can create different representations. Before going further, take a look at two different results in the PlayA and PlayB buttons and download the source code:
PlayAPlayBDownload

The Simple Builder

This first example looks at creating a simple Builder pattern with all of the parts laid out and pretty spread out. Two Client objects call two different concrete builders, and while that would have been pretty easy to do with a single Client the purpose of this first example is to clearly show each of the parts. In Part II, you’ll see a more streamlined and functional version of a Builder, but for now, it’s important to see how this thing works. Before going further, take a look at the Builder class diagram in Figure 1:

Figure 1: Builder Class Diagram (with Client added)

Figure 1: Builder Class Diagram (with Client added)

As noted in Figure 1, I added the Client, and according to the Gang of Four,

The client creates the Director object and configures it with the desired Builder object.

So, the Client, while not a participant in the pattern, is clearly a key collaborator. However, I put the Client code at the end of this post because its role must be understood in the context of the Builder’s key participants.

The Builder Interface

It’s difficult to know where to begin in describing the Builder pattern; but starting with the Interface helps show the main building blocks.

?View Code PHP 
< ?php
//IBuilder.php
interface IBuilder
{
        public function mainHead();
        public function subHead();
        public function buildNavH();
        public function buildNavV();
        public function buildGraphic();
        public function buildVideo();
        public function buildBodyText();
}
?>

In looking at the IBuilder interface, you can see what might be the parts of a Web page. Keeping in mind that this example is a simple one, the example is a Web page “wire framer.” That is, it creates a graphic outline of what the page will look like using SVG graphics generated dynamically in the program.
Continue reading ‘PHP Builder Design Pattern Part I: One Process, Many Representations’