Software Patterns - Factory Method

We continue our exploration of the creation patterns with a look at the Factory Method.  This is a pattern where we see that instantiation is sometimes better when deferred.  We do not always know all we need to at instantiation time.  Thus, we need a pattern to address holding off on that step until we have the required information.

The Factory Method Defined

It helps to start with the "Gang of Four" definition and then we will dig into that.

Define an interface for creating an object, but let subclasses decide which class to instantiate. The Factory method lets a class defer instantiation it uses to subclasses.

This pattern allows us to roughly replace the constructor for a class with retrieving an instance of some subclass.  For example, let's consider a candy machine.  Each item would have a "GetContents" method.  In some cases that may mean a handful of nuts, a candy bar, a stick of gum, etc.  When "purchaseCandy" is called it will deliver a candy subclass and the "GetContents" method would return a different class of food depending on the type purchased.

Applying The Pattern

The common usage of this is a sort of circular reference.  We find this in solutions that require an instance of an object, but that instance is different depending on the situation.  Much like the other creation patterns, we see this in database connectors (getConnection will be a different class for Oracle than MySQL), controls (getParent will be different for a button than a page), and almost any other sizable hierarchy. I like the example that Wikipedia includes.  In that case, there is a maze game.  The maze creates a series of rooms based on a collection sent in.  The rooms may be magical or normal.  Thus, you want the room to be able to provide a concrete instance as opposed to the maze creating it.  You might want to use an abstract factory, but this is a simpler pattern to implement.

Java, PHP, C#, etc.

A Factory Method is an interface in some cases, but a subclass can work as well.  In the case of an interface you create a base called Room (for the above example).  Then you implement the Room interface in a MagicRoom and a StandardRoom class.  Both of these have a getRoom method that is required of the Room interface. The inheritance approach is very similar.  You create a Room class as the base.  The MagicRoom and StandardRoom classes inherit from Room and override the getRoom method.  This approach works best when the base object (Room) makes sense on its own while the interface approach is better when the base is always abstract.  A DatabaseConnector would be such an example.  There is no way to properly construct a DatabaseConnector without specifying a concrete class that connects to a specific database. The Factory Method pattern is very similar to the ones we have seen before.  However, it is at the method level instead of the class level patterns we have looked at before this.