Introduction

If you've been using pattern-based programming with PHP for a while, then it's highly probably that you've already implemented the factory design pattern as part of the business logic that drives your web applications.

As you'll certainly know, building a factory class can be useful in certain situations. It can be particularly useful when you need to spawn a number of objects across a given application without having to worry too much about how these objects are created by the class in question. However, one thing is true for this class in particular: no matter how many objects are returned to client code, they always conform to the expectations of a predefined context.

In simpler terms, this implies that if you're going to build, for instance, online forms by using a form element factory class, this class will be used in an environment where these types of objects are expected by the application. Nonetheless, this design pattern should work well as long as you know the context where all the spawned objects are going to work. But what happens if you're trying to develop a PHP application that uses multiple contexts?

Say you're building a system that generates dynamic web pages, and all of their elements are created by using a factory class. Obviously, in this case, the type of objects returned to client code will depend completely upon the kind of web document being created, right? You can't simply spawn form objects in a web page where there isn't any online form to be included. Period.

So, there must be some way other than using a concrete factory class that allows you to create correct objects according to the context a PHP application is using for a particular instance. Naturally, this leads us straight to the implementation of another pattern, which is widely known as "abstract factory."

When the abstract factory pattern is applied, obviously there's an abstract factory class that defines the type of objects that will be created by the corresponding concrete factories (in other words, non-abstract). On its side, a concrete factory class is responsible for spawning the correct kind of objects that correspond to its context. This implies that, if an application uses multiple contexts, the non-abstract factory always will return to client code an object that conforms to the expectations of a given instance.

Does this sound a bit confusing? Fear not, because in this three-part series, I'm going to show you how to create an abstract factory class with copious friendly hands-on examples. Hopefully, by the end of this series, you should have a more intimate knowledge of how this useful pattern works.

With the preliminaries out of our way, let's learn together the basics of applying the abstract factory pattern with PHP 5. Let's go!