Factory Pattern

What Is a Factory Pattern?

Factories are just what their name implies: they are classes that create or construct something. In the case of objectoriented code languages, this means they construct and return an instance of a class type. They provide an encapsulation of code required to render an instance of an abstract class type as an implementation class. The factory can initialize, pull in data, configure, set state, and perform nearly any other creational operation needed for a class.

As stated above, factories use a base class type to create a class instance. This type can be in the form of either an abstraction or an interface, and based on that type, via creational methods, the factory renders a functional class that inherits or implements this type.

Let’s talk about some ways to use a factory that you might find useful. You might use a Factory pattern if you had a lot of creational logic for instances of a class type strewn throughout your code base. You might wish to consolidate this logic into one place for uniformity and maintainability. Instead of having to change logic in many places when you want to modify how the class is created, you could move it into a factory. Then you could change it in one place inside the factory instead of hunting through your code.

A factory might also be useful when you want to limit and define the accepted member implementations of a certain abstract class type for a particular logical flow, but do not want to define at compile time the logic for which type might be used. For example, you might pass in a key to the factory method instead of using a Boolean if...then... else statement to determine the class you want to construct and return from your factory. Doing that would free you from having to use compiled Boolean statements and instead allow something outside your factory to determine the logical flow of which implementation of a class type is rendered.

Factories can be static or creation only, or repositories, which both create and store references to the created products. But in general, factories provide a way to house the creational aspects of class types.

The Factory pattern has two main components: the Factory and the Product. The factory class is the class that renders the product class. The product class is the class containing data or functionality and is part of a series of class types that can be rendered from a factory method as an instance of an abstract type.

Comparison to Similar Patterns

Factories work well when returning a class type that is based on a base class. If, however, you need to perform several operations to create an object, a Builder pattern might be more appropriate. If you need uniformity over several factories to do the same work, consider an Abstract Factory pattern.

Abstract Factory Pattern

What Is an Abstract Factory Pattern?

The Abstract Factory pattern is a creative way to expand on the basic Factory pattern. Since the Factory pattern is a class that creates other classes in a uniform way, the Abstract Factory pattern gives us a way to allow factories with similar methods and access points to be interchangeable. That is, using an abstract factory we can define implementation class types as factories with the abstract factory as the base, and thereby tie in all the different factory implementations to a base class.

So now that we have a basic explanation of what an abstract factory is, let’s talk about how this is useful in our code. Let’s start by discussing what factories actually do in code and why they are valuable.

A factory class is a way to compartmentalize code that creates other classes and types. It can initialize, pull in data, configure, set state, and perform nearly any other creational operation needed. An abstract factory then is generally used when you may have multiple factories that do different things for a class type, and you wish to provide uniformity between these factories. So let’s say you have two different factories. Each one has slightly different creational logic and renders a particular class type. If each of these factories rendered the same class type, but differed in how they create the class type as an instance, we could tie both those factories together using an abstract factory class as a base. Now if we wanted to use the two factory classes interchangeably for different situations but still return the same class type, we could do so without having to rewrite the code that calls the factory to explicitly call a particular factory class type.

The Abstract Factory pattern has two main components: the Abstract Factory and the Abstract Product. The abstract factory class holds the definition for creating the concrete implementations of the factory, including the abstract method references. The abstract product class is the definition for the concrete implementations of the class that the factory renders.

Comparison to Similar Patterns

Abstract Factories are an abstraction of factory implementation, so whether to use a Factory or abstract the factory depends on your need. It may make more sense to use different factories inside a Builder or pass the factory into a Builder as an abstract one. Builders that accept Abstract Factories sometimes work better than Builders that accept one single factory type. Another option to the Abstract Factory is using a Builder with a director. The director accepts different builder types with operational methods and deals with each operational method in turn. This might be more useful if you have to implement several operations in the creational process instead of one. Factories usually are more useful with a specific class type or series of class types all subclassed from a single base. Abstract Factories are simply an expanded version of the Factory pattern, where the Factory needs to have a polymorphic implementation.

What We Have Learned

In the solutions we saw how to take different factories for classes with a common base, provide polymorphic cohesion between these class’s factories using the Abstract Factory pattern, and in effect simplify and/or enhance the overall code. We used this pattern to define a contract or common interface between factories used by similar objects, and using this contract allowed the base class to handle the actual factory call. We also learned a valuable lesson on polymorphism that incorporates similarities in interfaces between classes and, depending on the implementations of those classes, causes different actions to be performed. We found another positive aspect of polymorphism, in that it can enhance the maintainability of your code with respect to the way the factory implementation is used instead of having different multiple conditional logic areas either in classes or builders.

Tip You should derive all the objects your factory creates from the same base class or interface so that code that uses the objects it creates doesn’t have to be modified for each new object type.

Remember According to the GoF book, the Factory Method design pattern should “Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory method lets a class defer instantiation to subclasses.”