Creational Design Pattern: Factory Pattern

The Factory Pattern is a widely used design pattern used for the creation of object instances within an object orientated environment. The factory pattern allows us to hide the details of an object’s creation from the consumer, decoupling the consumer from an instance of an interface or a derivative of a base class.

The Factory Pattern can be used to replace the concept of class constructors, abstracting the creation of the object as to determine the construction logic at runtime. The most basic way to understand this is, you ask for an instance and the Factory Pattern Implementation provides it.

Advantages to using the Factory Pattern include;

  • Abstraction of complexity of selecting an interface implementation to use
  • Separates creation & use
  • Allows a wrapper to customise any logic required in the creation without having an effect upon the implementation itself
  • Places the creation logic in a single location
  • Allows for the management of a singleton lifecycle from within a Factory
  • Implementations are easily changed without affecting client code
  • Parameter specific instances can be easily created and stores
    • I.E – If class A requires an input parameter, say a number, which is the only change in state to the class, a series of singleton-esque instances can be created by caching a version of the class for each parameter requested.
    • If we request the class for 3 numbers, 1, 2 & 2, we would only maintain two instances of the class, one for the parameter 1, and one for the parameter 2.

Manufacturing

Since a Factory is typically associated with the manufacturing process, I’ll use a traditional example of creating a vehicle based on the current environment.

Here, we have an application that requires a Vehicle, based on the current Environment. By Environment, I don’t mean technical environment, but a representation of a physical location, for example, a field.

We begin by defining the interface of the vehicle;


public interface IVehicle

{
    Terrain Terrain { get; }
}

public enum Terrain

{
    Land,
    Sea,
    Air
}

Then we create the implementations of the interface;


public class Car : IVehicle

{

    Terrain Terrain { get { return Terrain.Land;  }}

}

public class Plane : IVehicle

{

    Terrain Terrain { get { return Terrain.Air;  }}

}

public class Boat: IVehicle

{

    Terrain Terrain { get { return Terrain.Sea;  }}

}

In our imaginary application, somewhere in a dank, dark and scary cellar we have a setting that tells us what the current Terrain is. This isn’t required for the Factory pattern, though it is necessary for this example to show why the factory Pattern may be used.


public static class CurrentLocation

{

    public static Terrain CurrentTerrain { get; set; }

}

Finally, we can implement the factory;


public static class VehicleFactory

{
public static IVehicle GetVehicle()
{
        if (CurrentLocation.CurrentTerrain == Terrain.Land)
        {
            return new Car();
        }
        else if (CurrentLocation.CurrentTerrain == Terrain.Air)
        {
            return new Plane();
        }
        else if (CurrentLocation.CurrentTerrain == Terrain.Sea)
        {
            return new Boat();
        }
        else
        {
            throw new Exception();
        }
    }
}

Now we have an implemented factory, the client code ca recieve a vehicle based on the current terrain setting, without having to affect any of the implementations, or have them be aware of each other. The calling client code simply cares it recieves an IVehicle, and nothing else about it matters.


IVehicle currentVehicle = VehicleFactory.GetVehicle();

Should the implementations change, or further Terrians be introduced to the application, only the factory needs to be aware, meaning the client code and implementations remain agnostic.

In all, The Factory Pattern is incredibly easy to implement, but also incredibly helpful. I imagine that at some point you will have seen one, even without realising that’s what a Factory Pattern looks like. Which can be said for most of the design patterns used in software architecture.

The client remains agnostic of the creation of the object, no matter how much the factory changes or the implementations themselves, the client code continues to function without requiring any changes.

About Adam Riddick

When not Developing, Adam moonlights as a climbing frame for his two children. Adam Riddick was founded in 1987, in County Durham, England. Read More ...

17. December 2014 by Adam Riddick
Categories: Achitecture, Design & Practice | Leave a comment

Inspire me with your wisdom ...