For my next several blogs I'm going to be discussing a powerful PHP design pattern, the factory. Since PHP applications and the data structures they interface with are getting larger and more complex there is a need to streamline and simplify how these data structures are loaded into useful objects.

For example, let's take robust CMS. A simple CMS has only one content type: a page. However, for more complex CMS systems you have multiple content types such as events, publications, and even products. Each one of these content types needs to have its own properties and methods that are unique to that content type. We end up with a problem. How do we deal with the unique needs for each type of content and maintain an efficient application?

It makes no sense whatsoever to include all of the properties and methods for every content type into a single class definition and database table. The class would be a behemoth. Once the object was loaded it would be a resource hog, eating up memory and processor power. On a small site with little traffic this might be ok, but any high volume CMS would grind to a halt under these conditions.

On the flip side, doing a new unique class for each content type is not much better. To request a piece of content then render it properly to the browser you would need to search across multiple classes and database tables. Not only that, because there are multiple tables, there could easily be URL and naming conflicts. Also, great care would have to be taken to ensure that all of these objects followed a common interface. If not, loading appropriate content could become a 'switch case' and 'if else' nightmare. Maintenance on that kind of system gives me the shivers just thinking about it.

Enter the factory design pattern. This design pattern lays out a few nice rules that simplify situations just like our example. First it would allow for a unified method for loading all content types, from one place. Second it would require consistency within all the classes. Everything would have to work the same way on a basic level, and the unique functionality would be in addition to that. There would be one central place where the core data was loaded, and then any extra information would be held in it's unique storage medium, such as a database table.

First let's look at what a factory is:

  • A factory is a class that is designed to load various types of objects that all share a common interface.
  • A factory class does nothing but load objects.
  • A factory intelligently decides what object should be loaded based on the parameters it is given.
  • Most often the objects a factory loads have a shared purpose.
Let's look at what defines the factory design pattern:
  • Classes the factory loads are structured in a similar way so that they can be loaded using the same basic method call.
  • Classes the factory loads follow a unified structure, most often defined by a parent class or an interface.
  • Classes the factory loads do not need anything from the factory once they are loaded. The factory's job is done.
As you can see, the factory pattern provides a means to load similar objects from one place. It is an extremely useful pattern within PHP web applications. In my next post I'll provide some UML and coding examples to flesh out this useful design pattern.