Thursday, June 17, 2010

Factory Method - 2nd Approach

Now we know that Factory method pattern is used for a creating object and lets its subclass to decide about which class to instantiate. This edition of blog will explain another mechanism or way of implementing the same pattern using Java 5 .

In last article we saw a shelf was able to accomodate any type of object by using parameterized Factory method and now we will take a Vehicle as an example in order to implement template type of Factory method.

Vechicle could be a Car,Plane,Bike,Bus etc , which ever the type of class instance the client needs should be available for it.

class Client
public static void main(String args[]){
ConcreteFactory cf=new ConcreteFactory();
Car c=cf.Create(Car.class);
System.out.println("Vechicle is :"+c.getName());

public interface Vehicle {
String getName();

public class Plane implements Vehicle {
String name="Boeing 777";
public String getName() {
return name;

public class Car implements Vehicle {
String name="Benz";
public String getName() {
return name;

public interface IFactory{
public <T extends Vehicle> T Create(Class<T> type);

public class ConcreteFactory implements IFactory {
public <T extends Vehicle> T Create(Class<T> type) {
try {
return type.newInstance();
} catch (InstantiationException e) {
System.out.println("Exception while instantiating..."+e);
return null;
} catch (IllegalAccessException e) {
return null;

Thumb Rule

o Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.

o Prototype doesn’t require subclassing, but it does require an Initialize operation. Factory Method requires subclassing, but doesn’t require Initialize.

o The advantage of a Factory Method is that it can return the same instance multiple times, or can return a subclass rather than an object of that exact type.

o Some Factory Method advocates recommend that as a matter of language design (or failing that, as a matter of style) absolutely all constructors should be private or protected. But it can create a new object or recycles an old one.

o The new operator considered harmful. There is a difference between requesting an object and creating one. The new operator always creates an object, and fails to encapsulate object creation. A Factory Method enforces that encapsulation, and allows an object to be requested without unresolvable coupling to the act of creation.


o If you have an inheritance hierarchy that uses polymorphism,then consider adding a polymorphic creation capability by defining a static factory method in the base class.

o Design the arguments to the factory method. What qualities or characteristics are necessary and sufficient to identify the correct derived class to instantiate?

o Consider designing an internal “object pool” that will allow objects to be reused instead of created from scratch.

o Consider making all constructors private or protected.

o The case when the Creator class is an abstract class and does not provide an implementation for the factory method it declares, requires the subclasses to define an implementation, because there's no reasonable default. It gets around the dilemma of having to instantiate unforeseeable classes.

o The case when the Creator is a concrete class and provides a default implementation for the factory method. It's also possible to have an abstract class that defines a default implementation, but this is less common. the concrete Creator uses the factory method primarily for flexibility. It's following a rule that says, "Create objects in a separate operation so that subclasses can override the way they're created." This rule ensures that designers of subclasses can change the class of objects their parent class instantiates if necessary.

No comments:

Post a Comment