See Design Patterns, part one; Introduction to get the definitions and the laws of design patterns.

Creational Patterns are used to isolate the details of object creation. They will help us stay under the law of low coupling. App controllers will be decoupled of object types and they will not change as new types arrived. Creational Patterns are about how an object can be created.

There are identified six patterns (more or less an exact number, they have not yet standardized the patterns):

• Singleton – only one instance can exist;
• Factory Method – creates an instance of several derived classes;
• Abstract Factory – creates an instance of several families of classes;
• Builder – to separate the construction from the representation to allow multiple different representations;
• Object Prototyping – creates objects based on a fully initialized instance (copy or clone);
• Object Pool – avoid expensive acquisition and recycle.

 

Singleton

You may use Singletons when your application needs one, and only one, instance of an object. The first intent is to prevent the client programmer from having any way to create an object except the ways you provide.

There are many examples of Singleton usage:

• any Factories as they are a global need;
• logging points;
• configuration classes;
• lookup service;
• accessing resources in shared mode.

There are several implementations of this pattern, but all make all constructors private and create at least one constructor to prevent the compiler from synthesizing a default constructor. Some of the theorists ask for lazy initialization, but I do not consider it a must. The Singleton design pattern is one of the most inappropriately used patterns. Singletons are intended to be used when a class must have exactly one instance, no more, no less. Programmers frequently use Singletons in a misguided attempt to replace global variables, why the hell are you using global data?

Object Pool

Sometimes objects are expensive (eg. db connections) and you can think about recycling them. This is a technique to create a limited pool of objects.

As a Factory Design it is a Singleton. Factories create the objects and then forget about them, but The Pool manages objects lifetime and keeps track of them.

Factory Method

The new operator is considered harmful and this pattern makes the difference between requesting an object and creating one. The new operator always creates an object and fails to encapsulate object creation. Factory Method enforces that encapsulation and allows an object to be requested without inextricable coupling to the act of creation.

When you need to add new types to the system the first idea is to use polymorphism as new types may be added without disturbing existing code. If the code that creates objects is distributed throughout your application, you must chase down all the points of your code where type matters and you will broke the night compilation. The solution is to force the creation in one place through a common Factory. As you get experience I suspect that Factories will be the most universally useful kinds of design patterns.

Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward more abstract as the designer needs more flexibility.

As OOD has two fundamental ways to relate classes – inheritance and composition here you may also think as two ways to create objects – Factory Method use creation through inheritance and Prototyping creation through delegation. Prototype doesn’t require subclassing, but it does require an Initialize operation. Factory Method requires subclassing, but doesn’t require Initialize.

The most used example is the injection mold press. Manufacturers of plastic toys process plastic molding powder and inject the plastic into molds of the desired shapes. The class of toy (car, action figure etc.) is determined by the mold.

Abstract Factory

Provide an interface for creating families of related or dependent objects without specifying their concrete classes. It is a natural evolution of Factories as modern applications can run on different platforms. If an application is to be portable, it needs to encapsulate platform dependencies (including UI, OS, DBs etc). The application must replace the entire family of products simply by instantiating a different concrete instance of the abstract factory. In other words, The Abstract Factory is a super-factory which creates other factories (Factory of factories).

Follow the law of simplicity and do not consider platform independency if not needed. To get one more abstraction layer just because you do not choose what DB to build on it is a very bad design. First to do is a Pro-Cons matrix of “platforms” versus “products”, sometimes it is easier and cheaper to build products on platforms.

Builder

The goal of Builder is to separate the construction from the representation to allow multiple different representations. The construction process stays the same, but the resulting object has different possible representations. The differentia of Builder in Factories is that it has multiple steps in creating an object and those steps are accessed externally to the Builder object.

An old lady thought me that McDonalds is using a builder process. Whether a customer orders a hamburger, cheeseburger or chicken the process is the same. The employee at the counter directs the crew to assemble a main item, side item and toy. These items and the drink are then placed in a bag.

Prototyping

The mitotic division of a cell – resulting in two identical cells – is an example of a prototype. The new operator is considered harmful and then we can consider build our own Factory that cache prototypical objects for use as breeders of all future instances. javascript is the common object-oriented language that relays on Prototyping.

A problem with the other Factory designs above is that they require a central location where all the types of the objects must be known: inside the factory( ) method. If new types are regularly being added to the system, the factory( ) method must be changed for each new type. When you discover something like this, it is useful to try to go one step further and move all of the information about the type, including its creation, into the class representing that type. This way, the only thing you need to do to add a new type to the system is to inherit a single class.

 

At the end I must emphasize that sometimes Creational Patterns are competitors: there are cases when either Prototype or Abstract Factory could be used properly. At other times they are complementary: Abstract Factory might store a set of Prototypes from which to clone and return product objects.

G.