| Name / AKA |
Intent / Description |
Ideas |
| Abstract Factory / Kit |
Provide an interface for creating families of related
or dependent objects without specifying their concrete
classes. /
Concrete Factory classes (inherited from Abstract Factory class)
contain methods for creating concrete products.
|
-
parameterize a system by the classes of objects it creates
by object composition
-
Determining object granularity by
creating other objects
-
Avoiding change-induced problems:
creating an object by specifying a class explicitly
-
Avoiding change-induced problems:
dependence on hardware and software platform
-
Avoiding change-induced problems:
dependence on object representations or implementations
-
Avoiding change-induced problems:
tight coupling
|
| Adapter / Wrapper |
Convert the interface of a class into another interface
clients expect. Adapter lets classes work together that
couldn't otherwise because of incompatible interfaces. /
The client invokes a request on Adapter (inherited
from Target). A "class" Adapter also inherits
from Adaptee to implement request, while an "object"
Adapter has a pointer to Adaptee and ivokes request on Adaptee
through the pointer.
|
-
provide a level of indirection after the fact
-
Avoiding change-induced problems:
inability to alter classes conveniently
|
| Bridge / Handle, Body |
Decouple an abstraction from its implementation so
that the two can vary independently. /
Client invokes operation on Abstraction which invokes
operationImp on Concrete Implementor which inherits from
Abstract Implementor.
|
-
provide a level of indirection before the fact
-
Avoiding change-induced problems:
dependence on hardware and software platform
-
Avoiding change-induced problems:
dependence on object representations or implementations
-
Avoiding change-induced problems:
tight coupling
-
Avoiding change-induced problems:
extending functionality by subclassing
|
| Builder |
Separate the construction of a complex object from its
representation so that the same construction process
can create different representations. /
Concrete Builder classes (inherited from Abstract Builder
class) contain methods for building the parts of a product.
|
-
parameterize a system by the classes of objects it creates
by object composition
-
Determining object granularity by
creating other objects
-
Avoiding change-induced problems:
algorithmic dependencies
|
| Chain of Responsibility / Percolator |
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. /
Concrete Handler(s) inherit from Abstract Handler which
has a successor reference to a Handler.
|
-
Decoupling senders and receivers by percolating
-
Class vs. interface using subtype
-
Avoiding change-induced problems:
dependence on specific operations
-
Avoiding change-induced problems:
tight coupling
-
Avoiding change-induced problems:
extending functionality by subclassing
|
| Command / Action, Transaction |
Encapsulate a request as an object, thereby letting you
parameterize clients with different requests, queue or
log requests, and support undoable operations. /
Client invokes Concrete Command (which inherits from
Abstract Command, which defines execute method) on a
Reciever (class which knows how to perform action).
Concrete Command execute method invokes Reciever's
action method.
|
-
Objects as arguments for a request
-
Decoupling senders and receivers by binding
-
Determining object granularity by
implementing a request on another object or group of objects
-
Class vs. interface using abstract class
-
Avoiding change-induced problems:
dependence on specific operations
-
Avoiding change-induced problems:
tight coupling
|
| Composite |
Compose objects into tree structures to represent part-whole
hierarchies. Composite lets clients treat individual objects
and compositions of objects uniformly. /
Tree is made up of Leaf Nodes and Composite Nodes, both of
which inherit from Component Node which defines child and parent
related methods.
|
-
recursive composition to organize an open-ended number of objects
affecting treatment
-
Finding the appropriate objects which treat objects uniformly
-
Class vs. interface using subclass
-
Avoiding change-induced problems:
extending functionality by subclassing
|
| Decorator / Wrapper |
Attach additional responsibilities to an object dynamically.
Decorators provide a flexible alternative to subclassing for
extending functionality. /
Concrete Component and Abstract Decorator inherit from Abstract
Component. Concrete Decorators inherit from Abstract Decorator.
Operation defined in Abstract Component is implemented by doing
base operation, and for Concrete Decorator, some other added stuff.
|
-
provide a level of indirection by adding properties
-
recursive composition to organize an open-ended number of objects
affecting responsibility
-
Specifying object interfaces by
using identical interfaces
-
Avoiding change-induced problems:
extending functionality by subclassing
-
Avoiding change-induced problems:
inability to alter classes conveniently
|
| Facade |
Provide a unified interface to a set of interfaces in a subsystem.
Facade defines a higher-level interface that makes the subsystem
easier to use. /
Methods capture processing logic.
|
-
Determining object granularity by
representing complete subsystem as object
-
Avoiding change-induced problems:
tight coupling
|
| Factory Method / Virtual Constructor |
Define an interface for creating an object, but let subclasses
decide which class to instantiate. Factory Method lets a class
defer instantiation to subclasses. /
Concrete Creator class (inherited from Abstract Creator class)
uses Factory method to create Concrete Product (inherited from
Abstract Product).
|
-
parameterize a system by the classes of objects it creates by subclassing
-
Avoiding change-induced problems:
creating an object by specifying a class explicitly
|
| Flyweight |
Use sharing to support large numbers of fine-grained objects
efficiently. /
Client gets
Concrete Flyweight (which inherits from Abstract Flyweight)
from Flyweight Factory (lazy initialization), passing extrinsic
state to methods.
|
-
Determining object granularity by
supporting huge numbers of objects at the finest granularities
|
| Interpreter |
Given a language, define a represention for its grammar along
with an interpreter that uses the representation to interpret
sentences in the language. /
Client parses statement into a tree. Nodes of the tree are
instances of Terminal Expression and Non Terminal Expression
which both inherit from Abstract Expression which defines
interpret(context) method. Subclasses implement interpret
to suit. Client invokes interpret operation on appropriate
nodes. Traversal is undefined.
|
|
| Iterator / Cursor |
Provide a way to access the elements of an aggregate object
sequentially without exposing its underlying representation. /
Concrete Aggregate (inherits from Abstract Aggregate) has
createIterator method which returns instance of Concrete
Iterator which inherits from Abstract Iterator.
|
-
Encapsulating variation in traversal
-
Avoiding change-induced problems:
algorithmic dependencies
|
| Mediator |
Define an object that encapsulates how a set of objects interact.
Mediator promotes loose coupling by keeping objects from referring
to each other explicitly, and it lets you vary their interaction
independently. /
Concrete Mediator (inherits from Abstract Mediator) controls
Concrete Colleagues which all inherit from Abstract Colleague
which has reference to Abstract Mediator.
|
-
Encapsulating variation in protocol
-
Encapsulating communication
-
Decoupling senders and receivers by indirect reference
-
Avoiding change-induced problems:
tight coupling
|
| Memento / Token |
Without violating encapsulation, capture and externalize an object's
internal state so that the object can be restored to this state later. /
Caretaker asks object (Originator) to save state. It returns a
Memento which caretaker stores. Object can be reset later
using Memento.
|
-
Objects as arguments for state
-
Specifying object interfaces by
encapsulating the internal state of an object
-
Avoiding change-induced problems:
dependence on object representations or implementations
|
| Observer / Dependents, Publish - Subscribe, Listener |
Define a one-to-many dependency between objects so that when one
object changes state, all its dependents are notified and updated
automatically. /
Concrete Subject (inherits from Abstract Subject) adds one (or more)
Concrete Observer (inherits from Abstract Observer) and notifies
Observer(s) when "registered" event occurs.
|
-
distributed communication
-
Decoupling senders and receivers by signaling
-
Class vs. interface using abstract class
-
Avoiding change-induced problems:
tight coupling
-
Avoiding change-induced problems:
extending functionality by subclassing
|
| Prototype |
Specify the kinds of objects to create using a prototypical instance,
and create new objects by copying this prototype. /
Client creates a new object by asking a Concrete Protype (inherited
from Abstract Prototype) to clone itself.
|
-
parameterize a system by the classes of objects it creates
by object composition
-
Avoiding change-induced problems:
creating an object by specifying a class explicitly
|
| Proxy / Surrogate |
Provide a surrogate or placeholder for another object to control
access to it. /
Concrete Subject and Proxy both inherit from Abstract Subject, which
is used by client. Proxy forwards request to Concrete Subject,
with possibility of added functionality.
|
-
provide a level of indirection by adding a stand-in
-
Specifying object interfaces by
using identical interfaces
-
Avoiding change-induced problems:
dependence on object representations or implementations
|
| Singleton |
Ensure a class only has one instance, and provide a global
point of access to it. /
Has static instance() method which returns unique instance.
If instance is null, then it instantiates (lazy initialization).
|
|
| State / Objects for States |
Allow an object to alter its behavior when its internal state
changes. The object will appear to change its class. /
Object is configured with one of several Concrete State objects
(inherited from Abstract State). It can change Concrete State
object during execution as state changes. It replaces one or
more "switch" statements.
|
-
Encapsulating variation in state-dependent behavior
-
Finding the appropriate objects which have
the state of an entity as an object
-
Class vs. interface using abstract class
-
Delegation of a request
to an object that represents state
|
| Strategy / Policy |
Define a family of algorithms, encapsulate each one, and make
them interchangeable. Strategy lets the algorithm vary independently
from clients that use it. /
Client is configured with Concrete Strategy which inherits from
Abstract Strategy.
|
-
Encapsulating variation in algorithm
-
Finding the appropriate objects which allow
interchangeable families of algorithms
-
Class vs. interface using abstract class
-
Delegation of a request
to an object that represents algorithm
-
Avoiding change-induced problems:
algorithmic dependencies
-
Avoiding change-induced problems:
extending functionality by subclassing
|
| Template Method |
Define the skeleton of an algorithm in an operation, deferring
some steps to subclasses. Template Method lets subclasses redefine
certain steps of an algorithm without changing the algorithm's
structure. /
Concrete Class (inherited from Abstract Class) overrides Abstract
Primitive Operations(s) which are invoked by Template of Abstract
Class (which should not be overridden).
|
-
Avoiding change-induced problems:
algorithmic dependencies
|
| Visitor |
Represent an operation to be performed on the elements of an
object structure. Visitor lets you define a new operation without
changing the classes of the elements on which it operates. /
Concrete Visitor inherits from Abstract Visitor, which has an
abstract VisitConcreteElementX(ConcreteElementX) for each Concrete
Element X, which inherit from Abstract Element, which defines
accept(Visitor). Traversal mechanism is undefined.
|
-
Objects as arguments for polymorphic operation
-
Determining object granularity by
implementing a request on another object or group of objects
-
Specifying object interfaces by
reflecting classes
-
Delegation of a request
to an object that traverses structure
-
Avoiding change-induced problems:
algorithmic dependencies
-
Avoiding change-induced problems:
inability to alter classes conveniently
|