A Simple PHP Design Pattern: The Factory Method

The Easiest Design Pattern in the Galaxy

As part of a Boston PHP group’s PHP Percolate, we’re going through Larry Ullman’s PHP Advanced and Object-Oriented Programming (3ed) book. In his chapter on Design Patterns, Larry has a pattern he calls, The Factory Pattern. This pattern can be found in many PHP works, and the first mention of the pattern that I found was in a series of PHP design patterns in an IBM Website in 2006. The Factory pattern was given an “honorable mention” as a pattern in the Freemans’ incredible work, Head First Design Patterns (p 117), but the Freemans note that the Factory pattern is more of a programming idiom than a true design pattern. The design pattern found in the Gang of Four’s work is a Factory Method pattern that is a true design pattern.

In looking at the Factory Method pattern, you can see two key participants—the Creator and the Product. The requesting object (Client), goes through the Creator to request a product. The key element in the Creator is an abstract method, factoryMethod(). Figure 1 shows a bare bones class diagram of the Factory Method:

Figure 1: Factory Method Class Diagram

In the Factory pattern, the simple factory is often declared statically (as is the case in Larry Ullman’s book), but in the Factory Method pattern, the factoryMethod() method is declared as an abstract one that can be overridden. The reason for that is flexibility. In Figure 1, you can see that a single concrete creator is instantiating a single concrete product. However, you can have several different concrete factories requiring different implementations of the factoryMethod(). In Chapter 5 of Learning PHP Design Patterns, one of the examples has two factories (concrete creators); one for graphics and another for text captions.

The Shape Factory

This example has one product, graphic shapes. It includes a red triangle, a green square, and a blue circle—-the RGB trio. The client requests each shape by specifying the name of the product in a request through the Creator. Figure 2 shows the class diagram for this implementation.

Figure 2: Class diagram for the Shape Factory

To get started, run the program and download the files using the buttons below:

Once you download the source code (not to mention the incredibly valuable graphics), you’re all set to understand just what’s going on.

Factory First

In working with design patterns, it helps to think in terms of what the client wants. (The client is perhaps the most important and most overlooked participant in design patterns.) So if you start with what the client wants, the next step is to ask, “How does the client get what it wants?”

1. Client wants a product.
2. The client must must request the product through the factory method

Now that’s fairly simple. The client is separated from the product it is requesting, and changes to the product will not affect the process used for making the request. Likewise, changes in the client request will not affect the nature of the requested product.

All we need for the Creator class is a factory method that will be implemented in the concrete creator(s). I added a protected property called $createProduct that can be used by the concrete creator.

//Creator.php
abstract class Creator
{
        protected $createdProduct;
        abstract public function factoryMethod(Product $productNow);
}
?>

An optional concrete operation (method) could be added to the abstract class, but this example is bare bones to focus on the factoryMethod().

The next step is to implement the Creator into a concrete class (implementation), ConcreteCreator. We need to include all of the concrete products that might be used; so that’s been done. It would be easier to use spl_autoload_register in the Client class, but this way, you can clearly see the product (concrete product classes) available for the factory to “manufacture.””

//ConcreteCreator.php
include_once('Creator.php');
include_once('Triangle.php');
include_once('Square.php');
include_once('Circle.php');
class ConcreteCreator extends Creator
{
        public function factoryMethod(Product $productNow)
        {
                $this->createdProduct=new $productNow();
                return($this->createdProduct->provideShape());
        }
}
?>

Note that the ConcreteCreator has no user constructor function (__construct); so the request from the Client will have to first create an instance of the ConcreteCreator and then call the factoryMethod() from the instance.

Products Please

The products that the factory is “building” are pretty simple. For this example, I just used URL strings to load up graphic files. However, you can create any kind of product you want, and as long as the interface is preserved, it will not affect the program adversely. In other words, the same request will just bring up the concrete product no matter how it is constructed. The first step is to create a Product interface.

//Product.php
interface Product
{
        function provideShape();
}
?>

The method, provideShape() is abstract (it has to be since it’s in an interface), and we’ll leave the implementation up to the concrete products. As long as the interface is preserved, we’re good to go. The first concrete product is the Triangle.

//Triangle.php
include_once('Product.php');
class Triangle implements Product
{
        public function provideShape()
        {
                return "products/triangle.png";
        }
}
?>

That’s pretty simple, and you could have just made a direct request from the Client for the same thing. The line,

would handle the request. However, with a much larger program, you want to be sure that when you make a change that everything will go along with the change and not crash the program. Beside, you can re-use the same pattern and even most of the code in a wholly different project.

The Square and Circle concrete products are similar.

//Square.php
include_once('Product.php');
class Square implements Product
{
        public function provideShape()
        {
                return "products/square.png";
        }
}
?>
 

//Circle.php
include_once('Product.php');
class Circle implements Product
{
        public function provideShape()
        {
                return "products/circle.png";
        }     
}
?>

Try adding different shapes or even re-write the concrete products to something more complex, and the structure holds up just fine.

The Client

The Client class is implied in the class diagram (light gray box and text), but in the original class diagram, it is not. I added it here to show where it could possibly be included. Often, the “client” is a requesting module in a much larger program, but in this case the Client’s role is easy to see simply as a requesting participant in the design pattern.

The Client does not use include_once to make the concrete products available. It is unnecessary for even though the call to the factoryMethod() includes the name of the class (e.g., Triangle()), the actual instantiation of the concrete product is done by the Creator. So there’s no need for the Client to include any of the concrete products it requests. Now that’s loose binding!

Further, notice that the factoryMethod() names concrete products (Triangle, Square, Circle), but the code hinting calls for the Product data type. This shows one of the key Design Pattern principles:

Program to the interface and not the implementation.

Because PHP does not have strict typing, we need some way to add a data type reference, and that’s done with type hinting. So by referencing the interface (the Product interface), our binding is much looser, more flexible (it accepts any implementation of the interface) and so our code is less likely to get tied up in knots, it’s easier to make changes and debugging is a snap. In other words we can spend more time on coding the program and less time untangling sequential or procedural code.

Now that we see how requests are made, we need our requester class; namely the Client. In 9 of the GoF design patterns, the Client is participant, in 4 more it is implied (grayed out), and in most of the others, it’s either mentioned or used in an example. Unfortunately, it somehow gets left out of most explanations of PHP design patterns. So here, I just want to acknowledge the Client and emphasize its importance in understanding design patterns.

In this example, the Client will request all three shapes (concrete products) and do so through the factoryMethod(). First, it instantiates an instance of the ConcreteCreator, and then uses a variable named $display to store the returned data from factoryMethod() that calls the requested concrete class by instantiating it as an argument of the factoryMethod(). Keep in mind that the type hinting in the Creator interface expects a Product data type, and because each of the three classes called are all child classes of the Product (Triangle, Square, and Circle), they are accepted. That’s because they share the interface of the Product. Any Product implementation that might be added will work as well. That’s programming to the interface instead of the implementation.

//Client.php
include_once("ConcreteCreator.php");
class Client
{
        public function __construct()
        {
                $shapeNow=new ConcreteCreator();
                $display=$shapeNow->factoryMethod(new Triangle());
                echo "$display>
";
                $display=$shapeNow->factoryMethod(new Square());
                echo "$display>
";
                $display=$shapeNow->factoryMethod(new Circle());
                echo "$display>
";
                echo "These shapes are brought to you by:
";
                echo "The Factory Method Design Pattern";              
        }     
}
$worker=new Client();
?>

Given all of the work that the factoryMethod() does in this implementation of the Factory Method pattern, it’s little wonder that it’s called The Factory Method and not The Factory pattern.

This was a simple example, and I hope it illustrates design pattern concepts that might be useful. Naturally, I’m very grateful to the Boston PHP group for running the Percolator program and those who have taken the time to be involved.

Copyright © 2013 William Sanders. All Rights Reserved.