I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Design Patterns Uncovered: The Factory Method Pattern

02.18.2010
| 64081 views |
  • submit to reddit

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 industrial building where workers manufacture goods or supervise machines processing 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. The definition of Factory Method provided in the original Gang of Four book on Design Patterns 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 xml
System.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 Creator
public abstract class AbstractLoggerCreator
{
//the factory method
public abstract Logger createLogger();


//the operations that are implemented for all LoggerCreators
//like anOperation() in our diagram
public Logger getLogger()
{
//depending on the subclass, we'll get a particular logger.
Logger logger = createLogger();

//could do other operations on the logger here

return logger;
}

}

The XMLLoggerCreator is our ConcreteCreator

//ConcreteCreator
public class XMLLoggerCreator extends AbstractLoggerCreator{

@Override
public 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.

Other Articles in This Series
The Observer Pattern
The Adapter Pattern
The Facade Pattern
The Factory Method Pattern
The Abstract Factory Pattern
The Singleton Pattern
The Strategy Pattern
The Visitor Pattern

Next Up

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

AttachmentSize
factory_pattern.PNG5.07 KB
Tags:

Comments

Yusuf Erdogan replied on Thu, 2010/02/18 - 1:10pm

Why not just pass a logger object that implements Logger? And it could be a parameter in constructor and an injector can handle it...

Reza Ghafari replied on Thu, 2010/02/18 - 8:41pm

As you mentioned, if the object tree is too big then using factory methods is complicated as we might need to create a lot of concrete factories. Abstract Factory can use factory method but I don't think it can replace it as it is used for a different propose of creating family of similar products in different object hierarchies. I like the concept of Prototype pattern for complicated structures.

Cheers,

Reza

 

 

James Sugrue replied on Fri, 2010/02/19 - 2:53am in response to: Reza Ghafari

Thanks for the comment Reza. I agree, Prototype may be better for more complicated structures

Fernando Gomez replied on Tue, 2010/07/20 - 11:35am

Hi. just a little question.
In the client class you you are calling the someMethodThatLogs() method wich includes this line:
Logger logger = logCreator.createLogger();
Shouldn't be:
Logger logger = logCreator.getLogger();
???
if you'r answer is NO then, whats the reason of creating a getLogger() method in the AbstractLoggerCreator class?? could you pleas explain it to me??.Sorry for the bad english and for the lack of knowledge (I'm a newbie at java). Regards from MX City.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.