Factory Method

Revision as of 02:04, 6 October 2008

(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.

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)

Let a subclasses of the creator to create an instance of a specific product. Creator class uses whatever the Product in the same way.

In the above diagram the anOperation() method has some code like:

product = FactoryMethod();

and the concrete implementation of the factoryMethod() in the ConcreteCreator class would have some code like:

return new ConcreteProduct;

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. For example:

Creator c;
Product p;

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

This code 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.

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.