Gof Design Patterns

Front 1

Back 1

Abstract Factory - Creational Pattern

Roles:

Abstract Factory: Interface to the actual factory.

Concrete Factory: Implements the Abstract Factory interface to create a specific class of object.

Abstract Product: The sort of product that the abstract factory creates.

Concrete Product: The actual object (whose class you don’t know) created by the factory.

Client: Uses the created objects only through their interfaces.

Front 2

Back 2

Builder - Creational Pattern

Roles:

Director: Builds an object without knowing exactly what it’s building.

Builder: Interface used by the Director to do the construction.

Concrete Builder: Actually builds the product by following directions given by the Director. Typically created externally (by the Client) or by an Abstract Factory.

Product: The object built by the Builder under the direction of the Director.

Front 3

Back 3

Factory Method - Creational Pattern

Roles:

Creator: Defines a method that needs to create an object whose actual type is unknown. Does so using abstract-method call

Concrete Creator: Derived class that overrides the abstract object instantiation method to create the Concrete Product.

Product: Interface implemented by the created product. Creator accesses the Concrete Product object through this interface.

Concrete Product: Object used by the Creator (base-class) methods, implements the Product interface.

Front 4

Back 4

Prototype - Creational Pattern

Roles:

Prototype: Interface of object to copy, must define a mechanism for cloning itself.

ConcretePrototype: Object that’s copied, implements cloning mechanism.

Client: Creates a new object by asking the Prototype for a clone.

Front 5

Back 5

Singleton - Creational Pattern

Singleton: The object being created, defines a class level (static) get-instance method that returns the instance. The class-level get-instance method may create the object if necessary.

Front 6

Back 6

Adapter - Structural Pattern

Roles:

Client: An object that collaborates with objects conforming to the target interface
Adaptee: An object that doesn’t support the desired interface

Target: The interface we want the Adaptee to support.

Adapters: The class that makes the Adaptee appear to support the Target interface.
Class Adapters use derivation.
Object Adapters use containment.

Front 7

Back 7

Bridge - Strutctural Pattern

Roles:

Abstraction: (Frame) A platform-independent portal into platform-specific code.

Implementor: (FramePeer) An interface used by the Abstraction to talk to a platform-specific implementation. Typically is also the Abstract Product of an Abstract Factory.

Refined Abstraction: (MyFrame) Often omitted, a version of the Abstraction, customized for a particular application.

Concrete Implementor: (WindowsFramePeer, MotifFramePeer) platform-specific implementation of Implementor

Front 8

Back 8

Composite - Structural Pattern

Roles:

Component: An interface or abstract class that represents all objects in the hierarchy.

Composite: A Component that can hold other

Components. It doesn’t know whether these subcomponents are other Composites or are Leaves.

Leaf: A Component that stands alone; it cannot contain anything.

Client: manipulates other objects in the composition through the Component interface.

Front 9

Back 9

Decorator - Structural Pattern

Roles:

Component: an interface for objects that can have responsibilities added to them (or have behavior modified) at runtime.

Concrete Component: an object to which additional responsibilities or new behavior is attached.

Decorator: wraps a Component and defines an interface that conforms to the Component’s interface.

Concrete Decorator: (implicit) extends the Decorator to define the additional behavior.

Front 10

Back 10

Facade - Structural Pattern

Roles:

Façade : Provides a simple interface to a complex subsystem.

Subsystem Classes: Classes that comprise one or more complex subsystems.

Front 11

Back 11

Flyweight - Structural Pattern

Roles:

Flyweight: Defines an interface for messages that use extrinsic state.

Concrete Flyweight: Implements Flyweight with methods that compute state information or get it from an external source (extrinsic state).

Unshared Concrete Flyweight: Implements Flyweight using internal state variables rather than extrinsic state.

Flyweight Factory: Creates and manages flyweights. Supplies an existing Concrete Flyweight if one exists, otherwise creates one.

Front 12

Back 12

Proxy - Structural Pattern

Roles:

Proxy: Maintains a reference, and controls access, to the Real Subject. Implements the same interface as the Real Subject so it can be used in its place.

Subject: An interface implemented by both the Proxy and the Real Subject, allows them to be used interchangeably.

Real Subject: The real object that the Proxy represents.

Front 13

Back 13

Chain of Responsibility - Behavioral Pattern

Roles:
Handler: Defines event-handling interface and optional successor link.

Concrete Handler: Handles request or, by doing nothing, causes event to be forwarded to successor.

Request: Strictly speaking, not part of the pattern, but often present. Encapsulates information about event that occurred in order to pass this information to the Handler.

Front 14

Back 14

Command - Behavioral Pattern

Roles:

Command: Defines an interface for executing an operation or set of operations.

Concrete Command: Implements the Command interface to perform the operation. Typically acts as an intermediary to a Receiver object.

Invoker: Asks the command to carry out a request.
Receiver: Knows how to carry out the request. This functionality is often built in to the Command object itself.

Front 15

Back 15

Iterator - Behavioral Pattern

Roles:

Iterator: interface for accessing and traversing elements.

Concrete Iterator: Implements Iterator and keeps track of current position.

Aggregate: Defines an interface for creating an iterator. (Omit if no Abstract Factory required.)
Concrete Aggregate: Holds the data. Implements the creation interface to manufacture an iterator.

Front 16

Back 16

Mediator - Behavioral Pattern

Roles:

Mediator: (Often omitted) defines an interface to Colleagues.

Concrete Mediator: Implements Mediator interface to interact with Colleagues and manage communication between them.

Colleagues: A system of interfaces and classes that communicate bidirectionally through the mediator rather than directly. Note that the client is a colleague

Front 17

Back 17

Memento - Behavioral Pattern

Roles:

Originator: Creates a memento that holds a “snapshot” of its current state.

Memento: Stores the internal state of the Originator in a way that does not expose the structure of the Originator. Supports a “wide” interface used by the originator and a “narrow” interface used by everyone else.

Caretaker: Stores the mementos, but never operates on them

Front 18

Back 18

Observer - Behavioral Pattern

Roles:

Subject: The Publisher—notifies Observers that some event has occurred. Keeps a subscription list and a means for modifying the list. Sometimes Subject is an interface implemented by a Concrete Subject.

Observer: Defines an interface for notifying observers.

Participant: Implements the Observer interface to do something when notified

Front 19

Back 19

State - Behavioral Pattern

Roles:

Context: Defines a public interface to the outside world, methods of which change behavior with object state. Maintains an instance of a Concrete State class.

State: Defines an interface that comprises all the behavior that changes with state.

Concrete State: Implements State to define behavior for a particular state.

Front 20

Back 20

Strategy - Behavioral Pattern

Roles:

Strategy: an interface that allows access to an algorithm.

Concrete Strategy: Implements a particular algorithm to conform to the Strategy interface.

Context: Uses the algorithm through the Strategy interface.

Front 21

Back 21

Template Method - Behavioral Pattern

Roles:

Abstract Class: Defines an algorithm that uses “primitive” operations that are supplied by a derived class.

Concrete Class: Implements the “primitive” operations

Front 22

Back 22

Visitor - Behavioral Pattern

Roles:

Visitor: Defines an interface that allows access to a Concrete Element of an object structure. Various methods can access elements of different types.

Concrete Visitor: Implements an operation to be performed on the Elements. This object can store an algorithm’s local state.

Element: defines an “accept” operation that permits a Visitor to access it.

Concrete Element: Implements the “accept” operation.

Object Structure: a composite object that can enumerate its elements.

Front 23

Back 23

Interpreter - Behavioral Pattern

Front 24

Creational Patterns

Back 24

Patterns that are all concerned with object creation. Most of them provide ways to create objects without knowing exactly what you’re creating beyond the interfaces supported by the created objects.

Front 25

Abstract Factory

Back 25

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

Front 26

Prototype

Back 26

Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.

Front 27

Builder

Back 27

Separates the construction of a complex object from its representation so that the same construction process can create different representations.

Front 28

Factory Method

Back 28

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Front 29

Singleton

Back 29

Ensure a class only has one instance, and provide a global point of access to it.

Front 30

Structural Patterns

Back 30

The structural patterns concern themselves with the organization of the program. Their intent is always to organize classes so that certain ends can be achieved. The whole point of this organization is that you can make changes to the program without having to change the dynamic model at all.

Front 31

Adapter

Back 31

Make a class appear to support a familiar interface that it doesn’t actually support. This way, existing code can leverage new, unfamiliar classes as if they are existing, familiar classes, eliminating the need to refactor the existing code to accommodate the new classes.

Front 32

Bridge

Back 32

Decouple an abstraction from its implementation so that the two can vary independently. In order to decouple subsystems so that either subsystem can change radically without impacting any code in the other one, put a set of interfaces between two subsystems and code to these interfaces.

Front 33

Composite

Back 33

Organize a runtime hierarchy of objects that represent whole/part (or container/content) relationships as a collection of objects that implement a common interface. Some of the implementers of this interfaces define stand-alone objects, others define containers that can hold additional objects, including other containers.

Front 34

Decorator

Back 34

Attach new responsibilities to (or modify the behavior of) an object at run time. Decorators can vastly simplify class hierarchies by replacing subclassing with containment.

Front 35

Facade

Back 35

Provide a single interface through which all the classes in a complex subsystem are manipulated. Façade allows you to treat a complex subsystem as if it were a single course-grained object with a simple easy-to-use interface.

Front 36

Flyweight

Back 36

To minimize memory use, make objects smaller by using extrinsic state (e.g. putting state information into a container or computing it on each access) and sharing (using multiple references to single objects rather than multiple copies of objects).

Front 37

Proxy

Back 37

Access an object through a “surrogate or placeholder” object. Proxy is applicable whenever there’s a need for a more sophisticated or versatile reference to an object than a pointer. You have seen this as Indirection in GRASP and it was used liberally in the persistence framework.

Front 38

Behavioral Patterns

Back 38

The behavioral patterns concern themselves with the runtime behavior of the program. They define the roles that objects take on and the way that these objects interact with each other. All of these objects are instances of the same class (or at least implement the same interface), so there’s not much in the way of structure in this pattern. It’s the dynamic behavior of the objects that are important.

Front 39

Chain of Responsibility

Back 39

A set of objects relay a message from one to another along a well defined route, giving more than one object a chance to handle the message. The object that’s best suited to field a given message actually does the handling. It’s possible for more than one object on the route to act on the message.

Front 40

Command

Back 40

Encapsulate a request or unit of work into an object. Command provides a more capable alternative to a function pointer because the object can hold state information, can be queued or logged, and so forth.

Front 41

Iterator

Back 41

Access the elements of an aggregate object sequentially without exposing how the aggregation is implemented.

Front 42

Mediator

Back 42

Define an object that encapsulates how a set of objects interact. Mediator simplifies your code by hiding complexity; it loosens coupling between the objects that use the mediator and the objects the mediator uses.

Front 43

Memento

Back 43

Encapsulate an object’s state in such a way that no external entity can know how the object is structured. An external object (called a caretaker) can store or restore an object’s state without violating the integrity of the object.

Front 44

Observer

Back 44

When an object changes states, it notifies other objects that have registered their interest at run time. The notifying object (publisher) sends an event (publication) to all its observers (subscribers).

Front 45

State

Back 45

Objects often need to change behavior when they are in certain states. A good solution defines an interface comprising all methods who change behavior; interface implementations define each state.

Front 46

Strategy

Back 46

Define an interface that defines a strategy for performing some operation. A family of interchangeable classes, one for each algorithm, implements the interface.

Front 47

Template Method

Back 47

Define an algorithm at the base-class level. Within the algorithm, call an abstract method to perform operations that can’t be generalized in the base class. This way you can change the behavior of an algorithm without changing its structure.

Front 48

Visitor

Back 48

Add operations to a “host” object by providing a way for a visitor—an object that encapsulates an algorithm—to access the interior state of the host object. Typically, this pattern is used to modify or examine the elements of a composite structure.

Front 49

Interpreter

Back 49

Pattern that specifies how to evaluate sentences in a language. The basic idea is to have a class for each symbol (terminal or nonterminal) in a specialized computer language. The syntax tree of a sentence in the language is an instance of the composite pattern and is used to evaluate (interpret) the sentence.