Factory Method

Latest revision as of 03:23, 25 November 2010

(This is summarised from GoF design patterns book)

Intent

The factory method is useful when you wish to define an interface for creating an object, but you want to let subclasses decide which class to create. Factory Method lets an abstract/normal class defer instantiation of an object of a different class to subclasses of the abstract/normal class.

It allows all fields of a particular type to be of an abstract type so that the class is more general. the factory can then be chosen to provide the concrete type that are desired for the fields.

This pattern is sometimes also called Virtual Constructor.

When to use it (Applicability)

Useful when:

• A class cannot anticipate the class of an object it must create.
• A class wants its subclasses to specify the objects it creates.
• Classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.

How it works (Structure)

The Factory Method lets a subclass of the Creator class create an instance of a specific product. Users of the factory method can then use the product without knowing specifically what type of product it is.

Typical creation of a product might be as follows:

Creator c;
Product p;

someMethod()
{
    c = new ConcreteCreator();
    p = c.factoryMethod();
    p.doStuff();
}

Participants

• Product: this defines the interface of objects the factory method creates.
• ConcreteProduct: this implements the Product interface.
• Creator: this class declares the factory method, which will return an object of type Product. Creator may also define a default implementation of the factory method that returns a default ConcreteProduct object but this really depends on what behaviour the developer requires. Creator, although abstract may have a method like the anOperation() method mentioned above, that simply calls the factoryMethod() to create a Product object.
• ConcreteCreator: this class overrides the factoryMethod() to return an instance of ConcreteProduct.

Consequences

• Factory methods eliminate the need to tie application-specific classes into your code. Your code will only have to deal with the Product interface, so this means it can work with any concrete subclass of Product.
  The code above, for example, is good because we don't care which subclass of Product p was actually instantiated with. We just call the method doStuff() which is defined in the abstract Product class and the subclass of Product that p was instantiated with just performs its concrete implementation of the doStuff() method.

• Clients might have to subclass the Creator class if they want to create a ConcreteProduct. This means that clients must now deal with any changes in the Creator class and overall need more knowledge of that part of the system.

• Factory methods provide hooks for subclasses who want to provide an extended version of an object, making extension easy. It makes your code more flexible than if you just create the object directly.

• Factory methods can be used to connect parallel class hierarchies.

• Violates the Dependency inversion principle

Example

You can find here a nicely explained java code example of the Factory Method Pattern usage in the real world.

Recognising the pattern

Classes: Creator, ConcreateCreator, Product, ConcreteProduct

• abstract protected createProduct() in Creator that returns a Product.
• concrete override of createProduct() in ConcreteCreator.
• abstract Creator class.
• Product interface/abstract class.

Related Patterns

• Abstract Factory: A Factory Method pattern is often used to implement part of an Abstract Factory.
• Template Method: Factory Methods are often called as part of a Template Method.
• Prototype: Prototype is a similar pattern but doesn't require subclassing the Creator. On the other hand, it needs an initialize operation on the Product class which is not required by Factory Method.
• Dependency injection

See also

• Abstract Factory