Use the Abstract Factory pattern when:

• a system should be independent of how its products are created, composed, and represented.
• a system should be configured with one of multiple families of products.
• a family of related product objects is designed to be used together, and you need to enforce this constraint.
• you want to provide a class library of products, and you want to reveal just their interfaces, not their implementations.

• AbstractFactory: declares an interface for opperations that create abstract product objects
• ConcreteFactory: implements the operations to create concrete product objects.
• AbstractProduct: declares an interface for a type of product object.
• ConcreteProduct:
  • defins a product object to be created by the corresponding concrete factory.
  • implements the AbstractProduct interface.
• Client: uses only interfaces declared by AbstractFactory and AbstractProduct classes.

• AbstractFactory classes:
  • often implemented as a Factory Method
  • can also be implemented as a Prototype
• Concrete Factory:
  • usually implemented as a Singleton.

Use the Builder pattern when

• the algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled.
• the construction process must allow different representations for the object that's constructed.

• Builder: specifies an interface for creating parts of a product object.
• ConcreteBuilder:
  • constructs/assembles parts of the product by implementing the Builder interface.
  • defins and keeps track of the created representation.
  • provides an interace for retrieving the product.
• Director: constructs an object using the Builder interface.
• Product:
  • represents the complex object under construction. ConcreteBuilder builds the product's internal representation and defines the process by which it's assembled.
  • includes classes that define the constituent parts, including interfaces for assembling the parts into the final result.

• Abstract Factory is similar to Builder in that it may also build complex objects. While, Abstract Factory focuses on families of product objects regardless of complexity, Builder focuses on constructing a complex object step-by-step. Abstract factory returns products immediately, but Builder returns the product as a final step.
• Composite is typically what a Builder builds.

Use the Factory Method pattern when:

• a class can't anticipate the class of objects it must create.
• a class wants its subclasses to specify the objects it creates.
• classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.

• Product: Defines the interface of objects the factory method creates.
• Concrete Product: Implements the Product interface.
• Creator:
  • Declares the factory method, which returns an object of type Product. Creator may also define a default implementation of the factory method that returns a default Concrete Product object.
  • May call the factory method to create a Product object.
• Concrete Creator: overrides the factory method to return an instance of a Concrete Product.

• Abstract Factory: is usually created with factory methods.
• Template Methods: Factory methods are usually called within Template Methods.
• Prototypes: don't require subclassing Creator. However, they often require an Initialize operation on the Product class. Creator uses Initialize to initialize the object. Factory Method doesn't require such an operation.

Use the Prototype pattern when a system should be de-coupled from how its products are created, composed, and represented; and:

• when the classes to instantiate are specified at run-time, for example, by dynamic loading; or
• to avoid building a class hierarchy of factories that parallels the class hierarchy of products; or
• when instances of a class can have one of only a few different combinations of state. It may be more convenient to install a corresponding number of prototypes and clone them rather than instantiating the class manually, each time with the appropriate state.

• Prototype: Declares an interface for cloning itself.
• Concrete Prototype: Implements an operation for cloning itself.
• Client: Creates a new object by asking a prototype to clone itself.

The Abstract Factory is a competing pattern in some ways but can also be used together with Prototype. For example, an Abstract Factory might store a set of prototypes from which to clone and return product objects.

Designs that make heavy use of the Composite and Decorator patterns often can benefit from Prototype as well.

Use the Singleton pattern when:

• a class must have exactly one instance, and it must be accessible to clients from a well-known access point.
• when the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code.

Singleton

• defines an Instance operation that lets clients access its unique instance. Instance is a class operation (that is, a class method in Smalltalk and a static member function in Java).
• may be responsible for creating its own unique instance.

Several patterns may be implemented using the Singleton pattern, such as:

• Abstract Factory
• Builder
• Prototype

Use the Adapter pattern when:

• you want to use an existing class who's interface does not match the one you need.
• you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces.
• (object adapter only) you need to use several existing subclasses, but it's impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class.

• Target: defines the domain-specific interface that Client uses.
• Client: collaborates with objects conforming to the Target interface.
• Adaptee: defines an existing interface that needs adapting.
• Adapter: adapts the interface of Adaptee to the Target interface.

• A class adapter uses multiple inheritance to adapt interfaces. The key to class adapters is to use one inheritance branch to inherit the interface and another branch to inherit the implementation.

• Bridge: Similar in structure, but Bridge's purpose is to separate an interface from its implementation, whereas an adapter is ment to change the interface of an existing object.
• Decorator: Enhances another object without changing its interface. Decorator is thus more transparent to the application than adapter is. Therefore, Decorator supports recursive composition, which isn't possible with pure adapters.
• Proxy: defines a representative or surrogate for another object and doesn't change its interface.

• Includes a "composite" abstract class that represents both primitives and their containers.
• Has a container class that:
  • extends the "composite" abstract class
  • contains a collection of "composite" child objects
  • implements container actions
  • implements primative actions recursively through child objects
• Has a primative class that:
  • extends the "composite" abstract class
  • implements container actions as impotent methods (i.e. adding a child to a primative does noting)
  • implements primative actions

Use the Composite pattern when:

• you want to represent part/whole hierarchies of objects.
• you want to let clients ignore the difference between compositions of objects and individual objects. Clients treat all objects in the composite structure uniformly.

• Component:
  • declares the interface for composition objects.
  • implements the default behavior for the common interface, as appropriate.
  • declares an interface for accessing and managing its subordinate components.
  • (optional) defines an interface for accessing a component's container in the recursive structure, and implements it if appropriate.
• Leaf:
  • represents end node objects in the composition and therefore has no children.
  • defines actions for primitive objects in the Component interface.
• Composite:
  • defines actions for components having subordinates.
  • stores subordinate components.
  • implements subordinate-related actions in the Component interface.
• Client: manipulates composition objects through the Component interface.

• Chain of Responsibility: Often uses the component-parent link.
• Decorator: is often used with Composite. When decorators and composites are used together, they usually have a shared parent class. So decorators have to support the Component interface with operations like Add, Remove, and GetChild.
• Flyweight: lets you share components, but they can no longer refer to their parents.
• Iterator: can be used to traverse composites.
• Visitor: localizes operations and behavior that would otherwise be distributed across Composite and Leaf classes.

Use the Bridge pattern when:

• You must avoid binding between an abstraction and its implementation. For example, when the implementation must be selected or switched at run time.
• both the abstractions and their implementations should be extensible by subclassing. In this case, the Bridge pattern lets you combine the different abstractions and implementations and extend them independently.
• changes in the implementation of an abstraction should have no impact on clients; that is, their code should not have to be recompiled.
• you have a proliferation of classes within a hierarchy that indicates the need for splitting an object into two parts.
• you want to share an implementation among multiple objects (perhaps using reference counting), and this fact should be hidden from the client.

• Abstraction:
  • defines the abstraction's interface.
  • maintains a reference to an object of type Implementor
• RefinedAbstraction: Extends the interface defined by Abstraction.
• Implementor: defines the interface for implementation classes. This interface doesn't have to correspond exactly to Abstraction's interface; in fact the two interfaces can be quite different. Typically the Implementor interface provides only primitive operations, and Abstraction defines higher-level operations based on these primitives.
• ConcreteImplementor: implements the Implementor interface and defines its concrete implementation.

• Abstract Factory: It can create and configure a specific Bridge.
• Adapter: is geared toward making unrelated classes work together. It is usually applied to systems after they're designed. Bridge, is typically used up-front in a design to let abstractions and implementations vary independently.

Use Decorator when:

• you must add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects.
• you must add responsibilities that can be withdrawn.
• extension by subclassing is impractical. Sometimes a large number of independent extensions are possibleand would produce an explosion of subclasses to support every combination. Or a class definition may be hidden
  or otherwise unavailable for subclassing.

• Component: defines the interface for objects that can have responsibilities added to them dynamically.
• ConcreteComponent: defines an object to which additional responsibilities can be attached.
• Decorator: maintains a reference to a Component object and defines an interface that conforms to Component's interface.
• ConcreteDecorator: adds responsibilities to the component.

• Adapter: A decorator is different from an adapter in that a decorator only changes an object's responsibilities, not its interface; an adapter will give an object a new interface.
• Composite: A decorator can be viewed as a degenerate composite with only one component. However, a decorator adds additional responsibilities—it isn't intended for object aggregation.
• Strategy: A decorator lets you change the skin of an object; a strategy lets you change the guts. These are two alternative ways of changing an object.

Use the Facade pattern to:

• provide a simple interface to a complex subsystem. Subsystems often increase in complexity as they evolve. Most patterns, when applied, result in more and smaller classes. This makes the subsystem more reusable and easier to customize, but it also becomes harder to use for clients that don't need to customize it. A facade provides a simple default view of the subsystem that is good enough for most clients. Only clients needing more customizability will need to look beyond the facade.
• decouple the subsystem from clients and other subsystems, thereby promoting subsystem independence and portability.
• layer your subsystems. Use a facade to define an entry point to each subsystem level. If subsystems are dependent, then you can simplify the dependencies between them by making them communicate with each other solely through their facades.

• Facade: delegates client requests to subsystem objects.
• Subsystem Classes:
• implement subsystem.
• perform work assigned by the Facade object.
• have no knowledge of the facade; that is, they keep no references to it.

• Abstract Factory: can be used with Facade to provide an interface for creating subsystem objects in a subsystem-independent way. Abstract Factory can also be used as an alternative to Facade to hide platform-specific classes.
• Mediator: is similar to Facade in that it abstracts functionality of existing classes. However, Mediator's purpose is to abstract arbitrary communication between colleague objects, often centralizing functionality that doesn't belong in any one of them. A mediator's colleagues are aware of and communicate with the mediator instead of communicating with each other directly. In contrast, a facade merely abstracts the interface to subsystem objects to make them easier to use; it doesn't define new functionality, and subsystem classes don't know about it.
• Singleton: Usually only one Facade object is required. Thus Facade objects are often Singletons.

Use the Flyweight pattern when all of the following are true:

• An application has a large number of objects.
• Storage costs are high because of the quantity of objects.
• Most object state can be extrinsic.
• Many groups of objects may be replaced by a smaller set of shared objects once extrinsic state is removed.
• The application does not depend on object identity. Since flyweight objects may be shared, identity tests return true for conceptually distinct objects.

• Flyweight: declares an interface through which flyweights can receive and act on extrinsic state.
• ConcreteFlyweight: implements the Flyweight interface and adds storage for intrinsic state, if any. A ConcreteFlyweight object is sharable. Any state it stores must be intrinsic.
• UnsharedConcreteFlyweight: not all Flyweight subclasses must be shared. The Flyweight interface enables sharing without enforcing it. It's common for UnsharedConcreteFlyweight objects to have ConcreteFlyweight objects as children at some level in the flyweight object structure.
• FlyweightFactory:
  • creates and manages flyweight objects.
  • ensures that flyweights are shared properly. When a client requests a flyweight, the FlyweightFactory object supplies an existing instance or creates one, if none exists.
• Client:
  • maintains a reference to flyweight(s).
  • computes or stores the extrinsic state of flyweight(s).

• Composite: The Flyweight pattern is often combined with the Composite pattern to implement a logically hierarchical structure in terms of a directed-acyclic graph with shared leaf nodes.
• State & Strategy: objects are often best implemented as flyweights.

Use a Proxy object there is a need for a more sophisticated reference to an object than a simple pointer. For example:

1. A remote proxy provides a local representative for an object in a different address space.
2. A virtual proxy creates expensive objects on demand.
3. A protection proxy controls access to the original object. Protection proxies are useful when objects should have different access rights.
4. A smart referenceis a replacement for a bare pointer that performs additional actions when an object is accessed. Typical uses include:
   • counting the number of references to the real object so that it can be freed automatically when there are no more references.
   • loading a persistent object into memory when it's first referenced.
   • checking that the real object is locked before it's accessed to ensure that no other object can change it.

• Proxy:
  • holds a reference that lets the proxy access the real subject. Proxy may refer to a Subject if the RealSubject and Subject interfaces are the same.
  • provides an interface identical to Subject's so that a proxy can by substituted for the real subject.
  • controls access to the real subject and may be responsible for creating and deleting it.
  • other responsibilities depend on the kind of proxy:
    • remote proxies are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space.
    • virtual proxies may cache additional information about the real subject so that they can postpone accessing it. For example, the ImageProxy from the Motivation caches the real image's extent.
    • protection proxies check that the caller has the access permissions required to perform a request.
• Subject: defines the common interface for RealSubject and Proxy so that a Proxy can be used anywhere a RealSubject is expected.
• RealSubject: defines the real object that the proxy represents.

• Adapter: An adapter provides a different interface to the object it adapts. In contrast, a proxy provides the same interface as its subject. However, a proxy used for access protection might refuse to perform an operation that the subject will perform, so its interface may be effectively a subset of the subject's.
• Decorator: Although decorators can have similar implementations as proxies, decorators have a different purpose. A decorator adds one or more responsibilities to an object, whereas a proxy controls access to an object.

Use Chain of Responsibility when:

• multiple objects may handle a request, and the handler isn't known a priori. The handler should be ascertained automatically.
• you must issue a request to one of several objects without explicitly specifying the receiver.
• the set of objects that can handle a request is specified dynamically.

• Handler:
  • defines an interface for handling requests.
  • (optional) implements the successor link.
• ConcreteHandler
  • handles requests for which it is responsible.
  • can access its successor.
  • if the ConcreteHandler can handle the request, it does so; otherwise it forwards the request to its successor.
• Client: initiates the request to a ConcreteHandler object on the chain.

Composite: Chain of Responsibility is often applied in conjunction with Composite. There, a component's parent can act as its successor.

• Action
• Transaction

Use the Command pattern when you want to:

• parameterize objects by an action to perform.
• specify, queue, and execute requests at different times.
• support undo by storing state history in the command object.
• support logging changes so that they can be reapplied in case of a system crash.
• structure a system around high-level operations built on primitives operations. Such a structure is common in information systems that support transactions.

• Command: declares an interface for executing an operation.
• ConcreteCommand:
  • defines a binding between a Receiver object and an action.
  • implements Execute by invoking the corresponding operation(s) on Receiver.
• Client: creates a ConcreteCommand object and sets its receiver.
• Invoker: asks the command to carry out a request.
• Receiver: understands how to perform the operations associated with carrying out a request. Any class may act as a Receiver.

• Composite: can be used to implement Macro Commands.
• Memento: can keep state the command requires to undo its effect.
• Prototype: A command that must be copied before being placed on the history list acts as a Prototype.

Use the Interpreter pattern when there is a language to interpret, and you can portray statements in the language as abstract syntax trees. The Interpreter pattern works best when:

• the grammar is simple
• efficiency is not a critical concern

• AbstractExpression: declares an abstract Interpret operation that is common to all nodes in the abstract syntax tree.
• TerminalExpression
  • implements an Interpret operation associated with terminal symbols in the grammar.
  • an instance is required for every terminal symbol in a sentence.
• NonterminalExpression
  • one such class is required for every rule R ::= R1 R2 ... Rn in thegrammar.
  • maintains instance variables of type AbstractExpression for each of the symbols R1 through Rn.
  • implements an Interpret operation for nonterminal symbols in the grammar. Interpret typically calls itself recursively on the variables representing R1 through Rn.
• Context: contains information that's global to the interpreter.
• Client
  • builds (or is given) an abstract syntax tree representing a particular sentence in the language that the grammar defines. The abstract syntax tree is assembled from instances of the NonterminalExpression and  TerminalExpression classes.
  • invokes the Interpret operation.

• Composite: the abstract syntax tree is an instance of the Composite pattern.
• Flyweight: shows how to share terminal symbols within the abstract syntax tree.
• Iterator: the interpreter can use an Iterator to traverse the structure.
• Visitor: can be used to maintain the behavior in each node in the abstract syntaxtree in one class.

Use the Iterator pattern:

• to access an aggregate object's elements without exposing its internal representation.
• to support multiple traversals of aggregate objects.
• to provide a uniform interface for traversing varying aggregate structures (that is, to support polymorphic iteration).

• Iterator: defines an interface for accessing and traversing elements.
• ConcreteIterator:
  • implements the Iterator interface
  • maintains the current position in the traversal of the aggregate.
• Aggregate: defines an interface for creating an Iterator object.
• ConcreteAggregate: implements the Iterator creation interface to return an instance of the proper ConcreteIterator.

Use the Mediator pattern when:

• a set of objects communicate in well-defined but complex ways. The resulting interdependencies are unstructured and difficult to understand.
• reusing an object is difficult because it refers to and communicates with many other objects.
• a behavior that's distributed between several classes should be customizable without a lot of subclassing.

Mediator: defines an interface for communicating with Colleague objects.

ConcreteMediator:

• implements cooperative behavior by coordinating Colleague objects.
• knows and maintains its colleagues.

Colleague classes:

• each Colleague class knows its Mediator object.
• each colleague communicates with its mediator whenever it would have otherwise communicated with another colleague.

• Facade differs from Mediator in that it abstracts a subsystem of objects to provide a more convenient interface. Its protocol is unidirectional; that is,
  Facade objects make requests of the subsystem classes but not vice versa. In contrast, Mediator enables cooperative behavior that colleague objects don't or can't provide, and the protocol is multidirectional.
• Colleagues can communicate with the mediator using the Observer pattern.

Use the Memento pattern when:

• a snapshot of (some part of) an object's state must be saved so that it can be restored to that state later, and
• a direct interface to obtaining the state would expose implementation details and violate the object's encapsulation.

Memento:

• stores internal state of the Originator object. The memento may store as much or as little of the originator's internal state as necessary at the originator's discretion.
• protects against access by objects other than the originator. Mementos have effectively two interfaces. Caretaker sees a narrow interface to the Memento—it can only pass the memento to other objects. The Originator, in contrast, sees a wide interface, one that lets it access all the data necessary to restore itself to its previous state. Ideally, only the originator that produced the memento would be permitted to access the memento's internal state.

Originator:

• creates a memento containing a snapshot of its current  internal state.
• uses the memento to restore its internal state.

Caretaker:

• is responsible for the memento's safekeeping.
• never operates on or examines the contents of a memento.

• Command: Commands can use mementos to maintain state for undoable operations.
• Iterator: Mementos can be used for iteration.

• Dependents
• Publish-Subscribe

Use the Observer pattern in any of the following situations:

• When an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets you vary and reuse them independently.
• When a change to one object requires changing others, and you don't know how many objects need to be changed.
• When an object should be able to notify other objects without making assumptions about what those objects are. In other words, you want to notify the other objects while maintaing loose coupling between these objects.

Subject:

• knows its observers. Any number of Observer objects may observe a subject.
• provides an interface for attaching and detaching Observer objects.

Observer: defines an updating interface for objects that should be notified of changes in a subject.

ConcreteSubject:

• stores state of interest to ConcreteObserver objects.
• sends a notification to its observers when its state changes.

ConcreteObserver:

• maintains a reference to a ConcreteSubject object.
• stores state that should stay in sync with the subject's.
• implements the Observer updating interface to keep its state in sync with the subject's.

Mediator: By encapsulating complex update semantics, the ChangeManager acts as mediator between subjects and observers.

Singleton: The ChangeManager may use the Singleton pattern to make it unique and universally accessible.

Objects for States

Use the State pattern in either of the following cases:

• An object's behavior depends on its state, and its run-time behavior must change depending on that state.
• Operations have large, multipart conditional statements that depend on the object's state. This state is usually represented by one or more enumerated constants. Often, several operations will contain this same conditional structure. The State pattern puts each branch of the conditional in a separate class. This lets you treat the object's state as an object in its own right that can vary independently from other objects.

Context:

• defines the interface of interest to clients.
• maintains an instance of a ConcreteState subclass that defines the current state.

State: defines an interface for encapsulating the behavior associated with a particular state of the Context.

ConcreteState subclasses: each subclass implements a behavior associated with a state of the Context.

• Flyweight: The Flyweight pattern explains when and how State objects can be shared.
• Singleton: State objects are often Singletons

Use the Strategy pattern when:

• many related classes differ only in their behavior. Strategies provide a way to configure a class with one of many behaviors.
• you need different variants of an algorithm. For example, you might define algorithms reflecting different space/time trade-offs. Strategies can be used when these variants are implemented as a class hierarchy of algorithms.
• an algorithm uses data that clients shouldn't know about. Use the Strategy pattern to avoid exposing complex, algorithm-specific data structures.
• a class defines many behaviors, and these appear as multiple conditional statements in its operations. Instead of many conditionals, move related conditional branches into their own Strategy class.

• Strategy: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy.
• ConcreteStrategy: implements the algorithm using the Strategy interface.
• Context:
• is configured with a ConcreteStrategy object.
• maintains a reference to a Strategy object.
• may define an interface that lets Strategy access its data.

Use the Template Method pattern:

• to implement the invariant parts of an algorithm once in a super class and leave it up to subclasses to implement the variable behavior.
• when common behavior among subclasses should be factored and localized in a common class to avoid code duplication. This is a good example of "refactoring to generalize" as described by Opdyke and Johnson. You first identify the differences in the existing code and then separate the differences into new operations. Finally, you replace the differing code with a template method that calls this/these new operation(s).
• to control subclasses extensions. You can define a template method that calls "hook" operations at specific points, thereby permitting extensions only at those points.

• AbstractClass:
• defines abstract primitive operations that concrete subclasses define to implement steps of an algorithm.
• implements a template method defining an algorithm skeleton. The template method calls primitive operations as well as operations defined in AbstractClass or those of other objects.
• ConcreteClass: implements the primitive operations to carry out subclass-specific steps of the algorithm in the parent class.

• Factory Method: These are often called by template methods.
• Strategy: Template methods use inheritance to vary part of an algorithm. Strategies use delegation to vary the entire algorithm.

Use the Visitor pattern when:

• an object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes.
• many distinct and unrelated operations need to be performed on objects in an object structure, and you want to avoid "polluting" their classes with these operations. Visitor lets you keep related operations together by defining them in one class. When the object structure is shared by many applications, use Visitor to put operations in just those applications that need them.
• the classes defining the object structure rarely change, but you often want to define new operations over the structure. Changing the object structure classes requires redefining the interface to all visitors, which is potentially costly. If the object structure classes change often, then it's probably better to define the operations in those classes.

Visitor: declares a Visit operation for each class of ConcreteElement in the object structure. The operation's name and signature identifies the class that sends the Visit request to the visitor. That lets the visitor determine the concrete class of the element being visited. Then the visitor can access the element directly through its particular interface.

ConcreteVisitor: implements each operation declared by Visitor. Each operation implements a fragment of the algorithm defined for the corresponding class of object in the structure. ConcreteVisitor provides the context for the algorithm and stores its local state. This state often accumulates results during the traversal of the structure.

Element: defines an Accept operation that takes a visitor as an argument.

ConcreteElement: implements an Accept operation that takes a visitor as an argument.

ObjectStructure:

• can enumerate its elements.
• may provide a high-level interface to allow the visitor to visit its elements.
• may either be a composite or a collection such as a list or a set.

• Composite: Visitors can be used to apply an operation over an object structure defined by the Composite pattern.
• Interpreter: Visitor may be applied to do the interpretation.