Archive for the 'Factory Method' Category

Page 2 of 2

A Simple PHP Design Pattern: The Factory Method

Published on January 31, 2013 by Bill Sanders in Factory Method and Introduction to Design Patterns. 4 Comments Tags: , , .

Factory250mThe 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

Figure 1: Factory Method Class Diagram

The Client makes a request using the desired product as an argument in the factoryMethod(). So, instead of asking for “product X,” its requests states, “Make me product X”—or “Factory, build product X for me.” This arrangement separates the requesting object (Client) from the requested product. Thus, it is a loose binding, and if changes are made in the product, the program does not crash and burn. That’s because the request is through the factory (Creator).

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

Figure 2: Class diagram for the Shape Factory


This example only includes shapes. However, suppose instead of general shapes, you had images with captions. Instead of starting all over again, you could just add another set of implemented Products for captions and had another concrete factory (concrete creator) for text. What’s important, you’re not wasting a lot of time re-doing what you’ve already done. The bigger the program, the more this kind of structure is appreciated.

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

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.
Continue reading ‘A Simple PHP Design Pattern: The Factory Method’

PHP Factory Method Design Pattern : Decoupling Your Products

Published on June 1, 2010 by Bill Sanders in Factory Method. 0 Comments

Let the Factory Build Your Products

One of the easiest design patterns to both understand and create is the Factory Method. However, the Gang of Four provide more than a single basic structure for the pattern and do not specify exactly where the Client makes its request. As a result, one may not recognize one implementation or another. Generally, I assume that requests from the Client class are made directly through the Creator class. However, some implementations suggest that the Client holds a reference to both the Creator and Product (GoF, 110). For this example I chose to use a parameterized version. In this version of the Factory Method pattern, the factory method is allowed to create multiple kinds of products. As noted by GoF,

The factory method takes a parameter that identifies the kind of object to create. All objects the factory method creates will share the Product interface.(pp. 110-111).

This approach calls for an abstract class that can handle a wide variety of concrete products. At the same time, though, we want it to be useful as well. For this example, the Product class has an abstract method to generate the concrete product (getData), but it also holds the properties with the connection values for the MySQL server. So this allows the developer to change the contents of the concrete products without having to even think about the connection values. (This assumes that the same connection information is used by all of the products.) Figure 1 shows the class diagram for this kind of Factory Method implementation.

Figure 1: Parameterized Factory Method Class Diagram

The Client’s role is implied to hold references to the Creator class (factory) and the Product class. The Product reference is through a parameter in the Creator instance. Because the the Creator interface holds a Product as its parameter in the form of a type hint, the request from the Client is to the abstract Product class and not the concrete product declared in the ConcreteCreator parameter. As a result, it’s easy to add more concrete products without having to re-write the whole program. You can just add the new concrete product class with the appropriate interfaces and call them with the Client referencing the concrete product as a parameter of the ConcreteCreator instance. For instance, the following lines shows such a request:

$this->graphicGetter=new ConcreteCreator();
print($this->graphicGetter->factoryMethod(new GraphicProduct()));

The same instance could be called again for a TextProduct. Therein lies the beauty of programming to the interface instead of the implementation. You can test the program and download the files by clicking the buttons below.

Note: When you look at the code in the downloaded files or in the listings, I used the MySQL settings from my localhost on my computer. Obviously, you will want to substitute those settings for your own; so be sure to get your own MySQL user, password, databases and tables set up before trying to run the files. Also, the project stemmed from a Dreamweaver PHP group whose names were substituted by known and unknown blues, boogie and jazz artists. Make changes in those elements to suit your tastes.

To better understand the actual program, click below to go to the steps in building the application:

Continue reading ‘PHP Factory Method Design Pattern : Decoupling Your Products’