Chain of Responsibility


Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.

Solution Overview

  • When a client issues a request, the request propagates along the chain until a ConcreteHandler object takes responsibility for handling it.


  • Handler (HelpHandler)

    • defines an interface for handling requests.

    • (optional) implements the successor link.

  • ConcreteHandler (PrintButton, PrintDialog)

    • handles requests it is responsible for.

    • 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.


The Chain of Responsibility design pattern is not known by another name.



Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

Solution Overview

  • The client creates a ConcreteCommand object and specifies its receiver.
  • An Invoker object stores the ConcreteCommand object.
  • The invoker issues a request by calling Execute on the command. When commands are undoable, ConcreteCommand stores state for undoing the command prior to invoking Execute.
  • The ConcreteCommand object invokes operations on its receiver to carry out the request.


  • Command

    • declares an interface for executing an operation.

  • ConcreteCommand (PasteCommand, OpenCommand)

    • defines a binding between a Receiver object and an action.
    • implements Execute by invoking the corresponding operation(s) on Receiver.

  • Client (Application)
    • creates a ConcreteCommand object and sets its receiver.

  • Invoker (MenuItem)

    • asks the command to carry out the request.

  • Receiver (Document, Application)

    • knows how to perform the operations associated with carrying out a request. Any class may serve as a Receiver.


The Command design pattern is also known as the Action, and the Transaction.



Decouple an abstraction from its implementation so that the two can vary independently.

Solution Overview

  • Abstraction forwards client requests to its Implementor object.


  • Abstraction (Window)

    • defines the abstraction's interface.
    • maintains a reference to an object of type Implementor.

  • RefinedAbstraction (IconWindow)

    • Extends the interface defined by Abstraction.

  • Implementor (WindowImp)

    • 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 (XWindowImp, PMWindowImp)

    • implements the Implementor interface and defines its concrete implementation.


The Bridge design pattern is also known as the Handle/Body.



Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

Solution Overview

  • Clients call operations on an Adapter instance. In turn, the adapter calls Adaptee operations that carry out the request.


  • Target (Shape)

    • defines the domain-specific interface that Client uses.

  • Client (DrawingEditor)

    • collaborates with objects conforming to the Target interface.

  • Adaptee (TextView)

    • defines an existing interface that needs adapting.

  • Adapter (TextShape)

    • adapts the interface of Adaptee to the Target interface.


The Adapter design pattern is also known as the Wrapper.

Abstract Factory


Provide an interface for creating families of related or dependent objects, without specifying their concrete classes.

Solution Overview

  • Normally a single instance of a ConcreteFactory class is created at run-time. This concrete factory creates product objects having a particular implementation. To create different product objects, clients should use a different concrete factory.
  • AbstractFactory defers creation of product objects to its ConcreteFactory subclass.


  • AbstractFactory (WidgetFactory)
    • declares an interface for operations that create abstract product objects.

  • ConcreteFactory (MotifWidgetFactory, PMWidgetFactory)
    • implements the operations to create concrete product objects.

  • AbstractProduct (Window, ScrollBar)
    • declares an interface for a type of product object.

  • ConcreteProduct (MotifWindow, MotifScrollBar)
    • defines 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.


The Abstract Factory design pattern is also known as the Kit.