Factory Method Pattern Tutorial with Java Examples

This article will focus on the Factory Method pattern, a variation on the simple factory. The Factory, as it's name suggests, is a pattern used to facilitate the creation of other objects. In a later article we'll be looking at the AbstractFactory.

Factories in the Real World 

It's easy to think of factories in the real world - a factory is just somewhere that items gets produced such as cars, computers or TVs. Wikipedia's definition of a real world factory is: 

A factory (previously manufactory) or manufacturing plant is an industrialbuilding where workers manufacturegoods or supervise machinesprocessing one product into another.

It's pretty clear what a factory does, so how does the pattern work?

Design Patterns Refcard
For a great overview of the most popular design patterns, DZone's Design Patterns Refcard is the best place to start. 

The Factory Method Pattern

Factory Method is known as a creational pattern - it's used to construct objects such that they can be decoupled from the implementing system. Thedefinition of Factory Method provided in the original Gang of Four book on DesignPatterns states: 

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

Now, let's take a look at the diagram definition of the Factory Method  pattern. The Creator hides the creation and instantiation of the Product from the client. This is a benefit to the client as they are now insulated from any future changes - the Creator will look after all of their creation needs, allowing to decoupling. Furthermore, once the Creator and the Product conform to an interface that the client knows, the client doesn't need to know about the concrete implementations of either. The factory method pattern really encourages coding to an interface in order to deal with future change.

Here the Creator provides an interface for the creation of objects, known as the factory method. All other methods in our abstract Creator are written only to operate on the Products created in the ConcreteCreator. The Creator doesn't create the products - that work is done by it's subclasses, such as ConcreateCreator.

Now let's take a look at a sequence diagram to see how this pattern behaves:

Here we see the client making a call to the abstract Creator, which then uses the factoryMethod() to get a new instance of the ConcreteProduct, complete's the anOperation() method and completes.

Where Would I Use This Pattern?

The idea behind the Factory Method pattern is that it allows for the case where a client doesn't know what concrete classes it will be required to create at runtime, but just wants to get a class that will do the job. The FactoryMethod builds on the concept of a simple Factory, but lets the subclasses decide which implementation of the concrete class to use.  You'll see factories used in logging frameworks, and in a lot of scenarios where the client doesn't need to know about the concrete implementations. It's a good approach to encapsulation.

So How Does It Work In Java?

This example will use the concept of a logger to illustrate the factory method. First, let's create our Product interface, in this case Logger:

//interface (Product)public interface Logger {public void log(String message);}

Next we'll create one ConcreteProduct named XMLLogger. Obviously, we would have many different loggers 

//concrete implementation of the Logger (Product) public class XMLLogger implements Logger {public void log(String message) {//log to xmlSystem.err.println("logging");}}

Next, we'll create our Creator, as a class with an abstract method that the concrete creator subclasses need to implement: 

//the abstract Creatorpublic abstract class AbstractLoggerCreator {//the factory methodpublic abstract Logger createLogger();//the operations that are implemented for all LoggerCreators//like anOperation() in our diagrampublic Logger getLogger(){//depending on the subclass, we'll get a particular logger.Logger logger = createLogger();//could do other operations on the logger herereturn logger;}}

The XMLLoggerCreator is our ConcreteCreator

//ConcreteCreatorpublic class XMLLoggerCreator extends AbstractLoggerCreator{@Overridepublic Logger createLogger() {XMLLogger logger = new XMLLogger();return logger;}}

Here's the client code to test drive our implementation of the pattern: 

public class Client {private void someMethodThatLogs(AbstractLoggerCreator logCreator){Logger logger = logCreator.createLogger();logger.log("message");}public static void main(String[] args){//for the purposes of this example, create an XMLLoggerCreator directly, //but this would normally be passed to constructor for use.AbstractLoggerCreator creator = new XMLLoggerCreator();Client client = new Client();client.someMethodThatLogs(creator);}}

As you can see, someMethodThatLogs, takes any AbstractLoggerCreator depending on who calls the method. So, if we wanted to log to a file, or the console, we would pass through the appropriate AbstractLoggerCreator implementations.

One thing that I have left out here is the possibility to pass a paramater through to the creator in order to choose which type of concrete class to create. For example, we could have made FileLoggerCreator that could take a string parameter, allowing us to choose between XML and flat files.

Watch Out for the Downsides

One thing I would note about this approach to the Factory is that it might be overcomplicated. Perhaps the Abstract Factory is a better approach for creating objects in a decoupled manner. We'll be discussing the Abstract Factory pattern next in the series, and will compare the two approaches then. If you want to create your own particular type of "Product" you would probably need to subclass a Creator. As with all design patterns, use it with caution, and make sure you need it.

In a lot of cases, a simple factory pattern will work fine. The FactoryMethod  just allows further decoupling, leaving it to the subclasses of the Creator to decide which type of concrete Product to create.

Next Up

Closely related to this FactoryMethod implementation is the other Factory pattern, the Abstract Factory.We'll get to that next time around.

Enjoy the Whole "Design Patterns Uncovered" Series:

Creational Patterns

• Learn The Abstract Factory Pattern
• Learn The Builder Pattern
• Learn The Factory Method Pattern
• Learn The Prototype Pattern

Structural Patterns

• Learn The Adapter Pattern
• Learn The Bridge Pattern
• Learn The Decorator Pattern
• Learn The Facade Pattern
• Learn The Proxy Pattern

Behavioral Patterns

• Learn The Chain of Responsibility Pattern
• Learn The Command Pattern
• Learn The Interpreter Pattern
• Learn The Iterator Pattern
• Learn The Mediator Pattern
• Learn The Memento Pattern
• Learn The Observer Pattern
• Learn The State Pattern
• Learn The Strategy Pattern
• Learn The Template Method Pattern
• Learn The Visitor Pattern