Bridge

The Bridge pattern has similar motivation as Adapter. However, the Adapter emphasizes the ability to change the interface of a given class while Bridge is supposed to separate the implementation details from the semantics (it seems that the interface of an Adapter is the semantics and the adaptee is the implementation details).

You can often take the Implementor as the Adaptee in Adaptor.

The important result of a Bridge is that the interface and implementation are decoupled and hence are easy to modify in future.

Adapter

An Adapter is used for adapting some existent classes to a certain interface. Usually we have two styles of Adapter, one realized with inheritance and the other with delegate.

It is a natural idea to have a class multiplely inherited from the interface and the implemented class. In this way, the inherited class can have a public interface and a private implementation which is intended to hide from the users. Hence the following figure illustrate the idea:

However, the class Adapter has some difficulty if it is used to adapt several Adaptees. In this case the follow method is preferable:

A two-way adapter can make two interfaces transparent.

Singleton

Sometime, only one instance of a certain class is needed. In this case, Singleton pattern helps.

In the figure above, the user is required to get the unique instance by calling Instance() which creates and maintains the object. The constructor is usually hidden by setting it protected so that the user can't instantiate it manually.

Of course, the idea can be applied in the case a fixed/variable number of instances are allowed to exists and the user shouldn't get involved in the maintainance of them. Static operations can be used, however it is less flexible because in this case there can be only one instance.

Prototype

In Abstract Factory, the different styles of products are realized in different subclasses of Abstract Factory. Though it is commonly desirable, when mixing different styles together, it is limited. What's more, it leads to too many subclasses. Prototype provides a way to eliminating unnecessary subclassing by adding a Clone() interface. This function is simply a copy constructor. Usually we have an auxiliary Prototype factory/manager (Client) that is instantiated with needed prototypes and produce the demanded parts by calling Clone().

What's more, by changing the Prototype manager dynamically, the products can also change dynamically and locally (which means only part of the products changes).

Factory Method and Template Method

When the sematics requires a procedure instantiate an object from a certain class/interface while the latter has to be instantiated in a specific concrete subclass, it is desirable to leave a pure virtual function in the interface of the former for creation of the object. This interface function must be implemented in the subclasses to create necessary concrete objects needed by the abstract procedure that calls it. Another paraphrase of the function is that it acts as a hook which must be filled in subclasses.

As you might guess, there will be as many subclasses of Creator as those of Product. However, the templates in C++ helps in this case by automating the parallel hiarachies.

The abstract procedure that calls Factory Methods are usually called Template Method, which is illustrated in the following figure:

Builder

What can we do when creating a complex object that consists of lots of small logic/semantic units? The separability of semantic and implementation is required to ensure later maintainance of code. Abstract Factory helps in this way. But as for a complex object, different directors are usually needed to create different versions. Hence it's better separate the directions and basic unit-creating interfaces. After the buiding procedure carried out by directors, the object can be handed to later applications.
Create a builder interface for creating basic units. It might not be a totally abstract class. Its subclasses implements different styles of units. It maintains the object to be built, however without directions, thus it can't build the desired object itself.
Get a director that contains a builder. It maintains the object to be built by delegating all basic building operations to the builder. Its subclasses or itself implement the semantic direction of weaving all units together.
The following picture shows how the two parts interacts with each other:

What's the difference between Abstract Factory and a builder? Well, an Abstract Factory does not maintain a complex objects to be built. In fact, it only provides a unified interface of creating objects of different styles. The Builder, more than providing different styles by subclasses, maintains a complex object, which means a Builder is aimed at building something and the semantic building is delegated to a director which commands the builder do what it wishes to.

Then it has the following cons and pros:

• It separates different styles of implementation from the semantic weaving.
• Usually, we have to provide a default building result for the top Builder (the interface).

Abstract Factory

Why should we bother with Abstract Factory? Because it separates implementaton of styles from functions. That's to say, when there are several styles of implementing something, which has nothing to do with logic or semantic functions in an upper level, we can follow the Abstract Factory's idea.

• For each logic unit, provide an interface that's used for later interaction. Different styles of implementations are subclasses of this interface.
• Create an interface for creating semantic products (units). Different styles are also implementation of this interface. However each subclass provides fully-functioned interface for creating all products in this style.

Here is a graphical illustration of Abstract Factory:

What are its advantages and disadvantages?

• If we want to add another style, the current framework can still be used without a change since the interface is fixed.
• If we want to add another logic/semantic unit, we have to add a function to the interface of Abstract Factory and implements all the styles of this logic/semantic unit. Thus it is a little difficult!
• Sometimes, there should be only one factory. Hence a singleton should be incorporated with it.

But be sure not to confuse styles and functions!