Home

About Me

Documents and Papers

Architectures

Design Patterns
Creational
Behavioral
Structural

Factory Creational Design Pattern

 

Previous page: Creational Category

Next page: Abstract Factory Pattern

Name: Factory - Creational Design Pattern

Motivation:
One defines an interface for creating objects, however one defers it to subclasses to decide what sort of object to create. This way the class that "uses" the object need not know what sort of object will be created.

Applicability: TBA

Participants: 


IFunction (Interface)        MobileDevice 
     |
     |
     |
     |
ConcreteFunctions<---------------ConcreteMobileDevice

- IFunction is the interface of the objects that are created by the factory.
- ConcreteFunction are the various types of functions that implement the interface
- MobileDevice declares the factory() method - it is this method that would return an object of the type     Concrete factory.
- ConcreteMobileDevice is a class that overrides the factory() method of MobileDevice to return a specific ConcreteMobileDevice.

Sample Code:

Four classes constitute the actual Pattern -  and I have also added a fifth class just to function as a Main()

//the interface that defines the objects to be created by the factory
public interface IFunctions { }

//ConcreteFunction
public class HSDPAFunction implements IFunctions {}

//ConcreteFunction
public class MusicFunction implements IFunctions {}

//ConcreteFunction
public class GPSFunction implements IFunctions {}

//this is the creator class - there are two common variations on this;
//one is where the creator class offers a default implementation of the
//factory method (e.g. in our case the AddFunctions() method) - in which case
//the class is not abstract
//the second option is, as we have done, that the factory method is completely
//abstract thus forcing the subclasses to implement their own factory methods
public abstract class MobileDevice
{
  private Vector<IFunctions> functions = new Vector<IFunctions>();

  public MobileDevice()
  { this.AddFunctions(); }

  public Vector getFunctions()
  {return functions;}

  public abstract void AddFunctions();
}

//this is a concrete creator - a subclass of MobileDevice. It implements the
//AddFunctions() method as it was declared as abstract, thus the subclasses
//(are forced to) define their own composition

public class SmartPhone extends MobileDevice
{
  public void AddFunctions()
  {
    this.getFunctions().add(new HSDPAFunction());
    this.getFunctions().add(new MusicFunction());
    this.getFunctions().add(new GPSFunction());
  }
}

public class PDA extends MobileDevice
{
  public void AddFunctions()
  { this.getFunctions().add(new GPSFunction()); }
}


//simple Main function
Main()
{
  MobileDevice[] devices =new MobileDevice[2];
  devices[0] = new PDA();
  devices[1] = new SmartPhone(); 

  for(int j=0; j<devices.length; j++)
  {
    System.out.println("--------------------------\n" + devices[j].getClass().getSimpleName());
    for(int i=0; i<devices[j].getFunctions().size(); i++)
    {
      System.out.println(" - " + devices[j].getFunctions().elementAt(i).getClass().getSimpleName());
    }
  }
}

OUTPUT:

--------------------------
PDA
    - GPSFunction
--------------------------
SmartPhone
    - HSDPAFunction
    - MusicFunction
    - GPSFunction

Known uses:
This pattern is widely used, and you might already have used it, more or less inadvertantly. The pattern can be used if one wishes to preserve flexibilty in for instance a "framework or toolkit" (p.115) [4] by delegating the responsibility of creating concrete classes to subclasses. The abstract class MobileDevice contains a llist / collection of type interface IFunctions, the concrete implementations of MobileDevice, that is the subclasses, contain in their list / collection objects that implement the IFunction interface. In this manner it is not necessary for the abstract class MobileDevice to know anything about what type of objects will be added to its list / collection - it only needs to know that they will implement the IFunction interface. In Java we can additionally use generics to make the list / collection type safe.

Related Patterns:
There are other related patterns, such as abstract factory and reflective factory

 

This site is W3C CSS Validated copyright Paul Austrem (c) 2007This site is W3C XHTML 1.0 Transitional Validated