Factory (object-oriented programming)

In class-based programming, a factory is an abstraction of a constructor of a class, while in prototype-based programming a factory is an abstraction of a prototype object. A constructor is concrete in that it creates objects as instances of a single class, and by a specified process (class instantiation), while a factory can create objects by instantiating various classes, or by using other allocation schemes such as an object pool. A prototype object is concrete in that it is used to create objects by being cloned, while a factory can create objects by cloning various prototypes, or by other allocation schemes.

Factories may be invoked in various ways, most often a method call (a factory method), sometimes by being called as a function if the factory is a function object (a factory function). In some languages factories are generalizations of constructors, meaning constructors are themselves factories and these are invoked in the same way. In other languages factories and constructors are invoked differently, for example using the keyword new to invoke constructors but an ordinary method call to invoke factories; in these languages factories are an abstraction of constructors but not strictly a generalization, as constructors are not themselves factories.

Terminology differs as to whether the concept of a factory is itself a design pattern – in the seminal book Design Patterns there is no "factory pattern", but instead two patterns (factory method pattern and abstract factory pattern) that use factories. Some sources refer to the concept as the factory pattern,[2][3] while others consider the concept itself a programming idiom,[4] reserving the term "factory pattern" or "factory patterns" to more complicated patterns that use factories, most often the factory method pattern; in this context, the concept of a factory itself may be referred to as a simple factory.[4] In other contexts, particularly the Python language, "factory" itself is used, as in this article.[5] More broadly, "factory" may be applied not just to an object that returns objects from some method call, but to a subroutine that returns objects, as in a factory function (even if functions are not objects) or factory method.[6] Because in many languages factories are invoked by calling a method, the general concept of a factory is often confused with the specific factory method pattern design pattern.

OOP provides polymorphism on object use by method dispatch, formally subtype polymorphism via single dispatch determined by the type of the object on which the method is called. However, this does not work for constructors, as constructors create an object of some type, rather than use an existing object. More concretely, when a constructor is called, there is no object yet on which to dispatch.[lower-alpha 2]

Using factories instead of constructors or prototypes allows one to use polymorphism for object creation, not only object use. Specifically, using factories provides encapsulation, and means the code is not tied to specific classes or objects, and thus the class hierarchy or prototypes can be changed or refactored without needing to change code that uses them – they abstract from the class hierarchy or prototypes.

More technically, in languages where factories generalize constructors, factories can usually be used anywhere constructors can be,[lower-alpha 3] meaning that interfaces that accept a constructor can also in general accept a factory – usually one only need something that creates an object, rather than needing to specify a class and instantiation.

For example, in Python, the collections.defaultdict class[7] has a constructor which creates an object of type defaultdict[lower-alpha 4] whose default values are produced by invoking a factory. The factory is passed as an argument to the constructor, and can itself be a constructor, or any thing that behaves like a constructor – a callable object that returns an object, i.e., a factory. For example, using the list constructor for lists:

# collections.defaultdict([default_factory[, ...]])
d = defaultdict(list)

The simplest example of a factory is a simple factory function, which just invokes a constructor and returns the result. In Python, a factory function f that instantiates a class A can be implemented as:

def f():
    return A()

A simple factory function implementing the singleton pattern is:

def f():
    if f.obj is None:
        f.obj = A()
    return f.obj

f.obj = None

This will create an object when first called, and always return the same object thereafter.

Factories may be invoked in various ways, most often a method call (a factory method), sometimes by being called as a function if the factory is a callable object (a factory function). In some languages constructors and factories have identical syntax, while in others constructors have special syntax. In languages where constructors and factories have identical syntax, like Python, Perl, Ruby, Object Pascal, and F#,[lower-alpha 5] constructors can be transparently replaced by factories. In languages where they differ, one must distinguish them in interfaces, and switching between constructors and factories requires changing the calls.

In languages where objects are dynamically allocated, as in Java or Python, factories are semantically equivalent to constructors. However, in languages such as C++ that allow some objects to be statically allocated, factories are different from constructors for statically allocated classes, as the latter can have memory allocation determined at compile time, while allocation of the return values of factories must be determined at run time. If a constructor can be passed as an argument to a function, then invocation of the constructor and allocation of the return value must be done dynamically at run time, and thus have similar or identical semantics to invoking a factory.

Factories are used in various design patterns, specifically in creational patterns such as the Design pattern object library. Specific recipes have been developed to implement them in many languages. For example, several "GoF patterns", like the "Factory method pattern", the "Builder" or even the "Singleton" are implementations of this concept. The "Abstract factory pattern" instead is a method to build collections of factories.

In some design patterns, a factory object has a method for every kind of object it is capable of creating. These methods optionally accept parameters defining how the object is created, and then return the created object.

Factory objects are common in toolkits and frameworks where library code needs to create objects of types which may be subclassed by applications using the framework. They are also used in test-driven development to allow classes to be put under test.[8]

Factories determine the actual concrete type of object to be created, and it is here that the object is actually created. As the factory only returns an abstract interface to the object, the client code does not know – and is not burdened by – the actual concrete type of the object which was just created. However, the type of a concrete object is known by the abstract factory. In particular, this means:

• The client code has no knowledge whatsoever of the concrete type, not needing to include any header files or class declarations relating to the concrete type. The client code deals only with the abstract type. Objects of a concrete type are indeed created by the factory, but the client code accesses such objects only through their abstract interface.
• Adding new concrete types is done by modifying the client code to use a different factory, a modification which is typically one line in one file. This is significantly easier than modifying the client code to instantiate a new type, which would require changing every location in the code where a new object is created.

Factories can be used when:

1. The creation of an object makes reuse impossible without significant duplication of code.
2. The creation of an object requires access to information or resources that should not be contained within the composing class.
3. The lifetime management of the generated objects must be centralized to ensure a consistent behavior within the application.

Factories, specifically factory methods, are common in toolkits and frameworks, where library code needs to create objects of types that may be subclassed by applications using the framework.

Parallel class hierarchies often require objects from one hierarchy to be able to create appropriate objects from another.

Factory methods are used in test-driven development to allow classes to be put under test.[9] If such a class Foo creates another object Dangerous that can't be put under automated unit tests (perhaps it communicates with a production database that isn't always available), then the creation of Dangerous objects is placed in the virtual factory method createDangerous in class Foo. For testing, TestFoo (a subclass of Foo) is then created, with the virtual factory method createDangerous overridden to create and return FakeDangerous, a fake object. Unit tests then use TestFoo to test the functionality of Foo without incurring the side effect of using a real Dangerous object.

Besides use in design patterns, factories, especially factory methods, have various benefits and variations.

    public class Complex
    {
        public double real;
        public double imaginary;

        public static Complex FromCartesian(double real, double imaginary)
        {
            return new Complex(real, imaginary);
        }

        public static Complex FromPolar(double modulus, double angle)
        {
            return new Complex(modulus * Math.Cos(angle), modulus * Math.Sin(angle));
        }

        private Complex(double real, double imaginary)
        {
            this.real = real;
            this.imaginary = imaginary;
        }
    }

Complex product = Complex.FromPolar(1, Math.PI);

public class ImageReaderFactory {
    public static ImageReader createImageReader(ImageInputStreamProcessor iisp) {
        if (iisp.isGIF()) {
            return new GifReader(iisp.getInputStream());
        }
        else if (iisp.isJPEG()) {
            return new JpegReader(iisp.getInputStream());
        }
        else {
            throw new IllegalArgumentException("Unknown image type.");
        }
    }
}

class Factory
{
    public static function build($type)
    {
        $class = "Format" . $type;
        if (!class_exists($class)) {
            throw new Exception("Missing format class.");
        }
        return new $class;
    }
}

interface FormatInterface {}

class FormatString implements FormatInterface {}
class FormatNumber implements FormatInterface {}

try {
    $string = Factory::build("String");
} catch (Exception $e) {
    echo $e->getMessage();
}

try {
    $number = Factory::build("Number");
} catch (Exception $e) {
    echo $e->getMessage();
}

There are three limitations associated with the use of the factory method. The first relates to refactoring existing code; the other two relate to extending a class.

• The first limitation is that refactoring an existing class to use factories breaks existing clients. For example, if class Complex were a standard class, it might have numerous clients with code like:

  Complex c = new Complex(-1, 0);
  

Once we realize that two different factories are needed, we change the class (to the code shown earlier). But since the constructor is now private, the existing client code no longer compiles.

• The second limitation is that, since the pattern relies on using a private constructor, the class cannot be extended. Any subclass must invoke the inherited constructor, but this cannot be done if that constructor is private.
• The third limitation is that, if the class were to be extended (e.g., by making the constructor protected—this is risky but feasible), the subclass must provide its own re-implementation of all factory methods with exactly the same signatures. For example, if class StrangeComplex extends Complex, then unless StrangeComplex provides its own version of all factory methods, the call

  StrangeComplex.FromPolar(1, Math.Pi);
  

  will yield an instance of Complex (the superclass) rather than the expected instance of the subclass. The reflection features of some languages can avoid this issue.

All three problems could be alleviated by altering the underlying programming language to make factories first-class class members (see also Virtual class).[10]