In an earlier article we saw what design patterns are and how they can help us. Today we’re going to take a look at the first category: creational patterns.

Creational design patterns deal with class creation and instantiation, and how to use those instances. Basic class creation could result in design problems or added complexity to the design. These patterns solve these problems by controlling this object creation.

Some examples of creational design patterns:

Abstract factory

The Abstract Factory Pattern implements a new level of abstraction in charge of creating families of related or dependent objects without directly specifying their concrete classes. The Factory object provides creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application – where it is instantiated. The application can replace the entire family of products simply by instantiating a different instance of the abstract factory.

Builder

The Builder Pattern separates the algorithm for interpreting a stored persistence mechanism from the algorithm for building and representing one of many target products. The focus is on creating highly-complex objects.

This pattern affords finer control over the construction process. Unlike creational patterns that construct products in one shot, the builder pattern constructs the product step by step.

Factory Method

The Factory Method pattern is the standard way to create objects. It is similar to the Abstract Factory, but without the emphasis on families. This pattern defines an interface for creating an object, but defers the actual creation to subclasses. A superclass specifies all standard and generic behavior, and delegates the creation details to subclasses that are supplied by the client.

Factory Methods are routinely specified by an architectural framework, and then implemented by the user of the framework.

Object Pool

The Object Pool pattern lets others “check out” objects from its pool, and when those objects are no longer needed by their processes, they are returned to the pool in order to be reused.

We don’t want processes to be idle waiting for a particular object to be released, so the Object Pool also instantiates new objects as they are required. Furthermore, this pattern must also implement a facility to clean up unused objects periodically.

Prototype

The Prototype pattern creates new instances of an object by cloning others already in used, rather than by actually creating a new one. To do so, an abstract class must be declared specifying a pure virtual clone() method. Any class that needs a polymorphic constructor capability derives itself from the abstract base class, implementing the clone() operation.

The client then, instead of writing code that invokes the new() operator, calls a clone() operation on the abstract base class, indicating the particular concrete derived class desired.

Singleton

The Singleton pattern is used when the application needs one, and only one, instance of an object. By using this pattern, a global access point to the instance is provided, and the instance is created when the first access is made.

When choosing which ones to use, keep in mind that sometimes creational patterns are complementary, so you might be able to use more than one of these.

Further reading

Related posts:

  1. Software design patterns (III): structural patterns
  2. Software design patterns (I)
  3. Software design patterns (IV): behavioral patterns