The Factory Design Pattern

The factory design pattern is one of the original design patterns by the Gang of Four. It follows the idea of using implementation of interfaces instead of different classes, and allows you to request a object from the factory.

Now design patterns are not specific to a language. You will find that sometimes these patterns work better in a given language, but they are not specific to a language, so if you search for “Factory Design Pattern” your search engine will suggest other queries for you.

This pattern is a creational pattern that uses factory methods to deal with the problem of creating objects without having to specify the exact class of the object that will be created. This is done by creating objects by calling a factory method—either specified in an interface and implemented by child classes, or implemented in a base class and optionally overridden by derived classes—rather than by calling a constructor. – Wikipedial

In Java constructors are not polymorphic. That means the constructor itself cannot create but that object for which it is enclosed. But allowing a subclass to create an object, we are adding polymorphic behavior to the instantiation. Essentially we are creating Pseudo polymorphism by letting the subclass to decide what to create.

Let’s look at a simple example. We have a series of shapes, and we want to build a shape based upon what is passed in to the factory. We’ll start with an abstract class, or you could use an interface.

public abstract class Shape {
    public abstract String draw();
}

Next we’ll create a few classes which extend this abstract class. You can have as many classes as you like, I’m just going to show one.

public class Circle extends Shape {
    public Circle() {

    }
    
    @Override
    public String draw() {
        return "I'm drawing a circle.";
    }
}

Next we’ll create a Factory object which can create objects. Now we can use a static method to do this if you want.

public class Factory {
    
    public static Shape getShape(String type) {
        if(type.equalsIgnoreCase("circle")) {
            return new Circle();
        } else if(type.equalsIgnoreCase("square")) {
            return new Square();
        }
        return null;
    }
}

Notice I have a getShape() method. I could have multiple factories within this object if I wanted to…

Now we’ll finally call these methods.

public class FactoryExample1 {

    public static void main(String args[]) {
        Shape circle = Factory.getShape("circle");
        Shape square = Factory.getShape("SQUARE");

        System.out.println(circle.draw());
        System.out.println(square.draw());
    }
    
}

To which will output:

I'm drawing a circle.
I'm drawing a square.

For simple projects, a factory doesn’t make sense, as you know about the few types of classes you might have. This example shows how much extra work goes into setting up a factory for just a few classes.

However, in a large complex project, which might have 100s of types of classes which can be instantiated, then it makes sense to use a factory. Especially if you want to provide protection from creating an object which maybe you shouldn’t be able to. You can do this with additional tests in your if conditional block.

An example might be of an online store which sells a variety of items. Now all items might have some basic attributes, such as items in stock, name, price, etc. However, some products might have additional attributes and therefore additional classes would be needed.

Since we might be constantly adding new product types, we need a simple and efficient way to handle this.

In some languages, you have a class exists type of function, which lets you know if a class exists and if so, you can return it, or if not, you can throw and exception.

The Factory Design Pattern was originally found on Access 2 Learn