Design Patterns Flashcards
Creational Patterns
Used to construct objects such that they can be decoupled from their implementing system.
Structural Patterns
Used to form large object structures between many disparate objects.
Behavioural Patterns
Used to manage algorithms,
relationships, and responsibilities between objects.
Object Scope
Deals with object relationships that can be
changed at runtime.
Class Scope
Deals with class relationships that can be changed at compile time.
Creational Patterns (5)
- Abstract Factory
- Builder
- Factory Method
- Prototype
- Singleton
Structural Patterns (7)
- Adapter
- Bridge
- Composite
- Decorator
- Facade
- Flyweight
- Proxy
Behavioural Patterns (11)
- Chain of Responsibility
- Command
- Interpreter
- Iterator
- Mediator
- Memento
- Observer
- State
- Strategy
- Template Method
- Visitor
Chain of Responsibility Purpose
Gives more than one object an opportunity to handle a request
by linking receiving objects together.
Use Chain of Responsibility When
- Multiple objects may handle a request and the handler
doesn’t have to be a specific object. - A set of objects should be able to handle a request with the
handler determined at runtime. - A request not being handled is an acceptable potential
outcome.
Command Purpose
Encapsulates a request allowing it to be treated as an object.
This allows the request to be handled in traditionally object-based relationships such as queuing and callbacks.
Use Command When
- You need callback functionality.
- Requests need to be handled at variant times or in variant orders.
- A history of requests is needed.
- The invoker should be decoupled from the object handling the
invocation.
Interpreter Purpose
Defines a representation for a grammar as well as a mechanism
to understand and act upon the grammar.
Use Interpreter When
- There is grammar to interpret that can be represented as
large syntax trees. - The grammar is simple.
- Efficiency is not important.
- Decoupling grammar from underlying expressions is desired.
Iterator Purpose
Allows for access to the elements of an aggregate object
without allowing access to its underlying representation.
Use Iterator When
- Access to elements is needed without access to the entire
representation. - Multiple or concurrent traversals of the elements are needed.
- A uniform interface for traversal is needed.
- Subtle differences exist between the implementation details
of various iterators.
Mediator Purpose
Allows loose coupling by encapsulating the way disparate sets of
objects interact and communicate with each other. Allows for the
actions of each object set to vary independently of one another.
Use Mediator When
- Communication between sets of objects is well defined
and complex. - Too many relationships exist and common point of control
or communication is needed.
Memento Purpose
Allows for capturing and externalizing an object’s internal
state so that it can be restored later, all without violating
encapsulation.
Use Memento When
- The internal state of an object must be saved and restored
- Internal state cannot be exposed by interfaces without exposing
implementation. - Encapsulation boundaries must be preserved.
Observer Purpose
Lets one or more objects be notified of state changes in other
objects within the system.
Use Observer When
- State changes in one or more objects should trigger behaviour
in other objects - Broadcasting capabilities are required.
- An understanding exists that objects will be blind to the expense of notification.
State Purpose
Ties object circumstances to its behaviour, allowing the object
to behave in different ways based upon its internal state.
Use State When
- The behaviour of an object should be influenced by its state
- Complex conditions tie object behaviour to its state.
- Transitions between states need to be explicit.
Strategy Purpose
Defines a set of encapsulated algorithms that can be swapped
to carry out a specific behaviour.
Use Strategy When
- The only difference between many related classes is their behaviour.
- Multiple versions or variations of an algorithm are required.
- Algorithms access or utilize data that calling code shouldn’t be exposed to.
- The behaviour of a class should be defined at runtime.
- Conditional statements are complex and hard to maintain.
Template Method Purpose
Identifies the framework of an algorithm, allowing implementing
classes to define the actual behaviour.
Use Template Method When
- A single abstract implementation of an algorithm is needed.
- Common behaviour among subclasses should be localized to a
common class. - Parent classes should be able to uniformly invoke behaviour in their subclasses.
- Most or all subclasses need to implement the behavior.
Visitor Purpose
Allows for one or more operations to be applied to a set of objects
at runtime, decoupling the operations from the object structure.
Use Visitor When
- An object structure must have many unrelated operations performed upon it.
- The object structure can’t change but operations performed on it can.
- Operations must be performed on the concrete classes of an object structure.
- Exposing the internal state or operations of the object structure is acceptable.
- Operations should be able to operate on multiple object
structures that implement the same interface sets.
Adapter Purpose
Permits classes with disparate interfaces to work together by
creating a common object by which they may communicate
and interact.
Use Adapter When
- A class to be used doesn’t meet interface requirements.
- Complex conditions tie object behaviour to its state.
- Transitions between states need to be explicit.
Bridge Purpose
Defines an abstract object structure independently of the
implementation object structure in order to limit coupling.
Use Bridge When
- Abstractions and implementations should not be bound at
compile time. - Abstractions and implementations should be independently
extensible. - Changes in the implementation of an abstraction should
have no impact on clients. - Implementation details should be hidden from the client.
Composite Purpose
Facilitates the creation of object hierarchies where each object
can be treated independently or as a set of nested objects
through the same interface.
Use Composite When
- Hierarchical representations of objects are needed.
- Objects and compositions of objects should be treated uniformly.
Decorator Purpose
Allows for the dynamic wrapping of objects in order to modify
their existing responsibilities and behaviors.
Use Decorator When
- Object responsibilities and behaviours should be dynamically
modifiable. - Concrete implementations should be decoupled from
responsibilities and behaviours. - Subclassing to achieve modification is impractical or impossible.
- Specific functionality should not reside high in the object hierarchy.
- A lot of little objects surrounding a concrete implementation is
acceptable
Facade Purpose
Supplies a single interface to a set of interfaces within a system.
Use Facade When
- A simple interface is needed to provide access to a complex system.
- There are many dependencies between system implementations
and clients. - Systems and subsystems should be layered.
Flyweight Purpose
Facilitates the reuse of many fine grained objects, making the
utilization of large numbers of objects more efficient.
Use Flyweight When
- Many like objects are used and storage cost is high.
- The majority of each object’s state can be made extrinsic.
- A few shared objects can replace many unshared ones.
- The identity of each object does not matter.
Proxy Purpose
Allows for object level access control by acting as a pass through
entity or a placeholder object.
Use Proxy When
- The object being represented is external to the system.
- Objects need to be created on-demand.
- Access control for the original object is required.
- Added functionality is required when an object is accessed.
Abstract Factory Purpose
Provide an interface that delegates creation calls to one or
more concrete classes in order to deliver specific objects.
Use Abstract Factory When
- The creation of objects should be independent of the system utilizing them.
- Systems should be capable of using multiple families of objects.
- Families of objects must be used together.
- Libraries must be published without exposing implementation details.
- Concrete classes should be decoupled from clients.
Builder Purpose
Allows for the dynamic creation of objects based upon easily
interchangeable algorithms.
Use Builder When
- Object creation algorithms should be decoupled from the system.
- Multiple representations of creation algorithms are required.
- The addition of new creation functionality without changing
the core code is necessary. - Runtime control over the creation process is required.
Factory Method Purpose
Exposes a method for creating objects, allowing subclasses to
control the actual creation process.
Use Factory Method When
- A class will not know what classes it will be required to create.
- Subclasses may specify what objects should be created.
- Parent classes wish to defer creation to their subclasses.
Prototype Purpose
Create objects based upon a template of an existing objects
through cloning.
Use Prototype When
- Composition, creation, and representation of objects should
be decoupled from a system. - Classes to be created are specified at runtime.
- A limited number of state combinations exist in an object.
- Objects or object structures are required that are identical or closely resemble other existing objects or object structures.
- The initial creation of each object is an expensive operation.
Singleton Purpose
Ensures that only one instance of a class is allowed within a system.
Use Singleton When
- Exactly one instance of a class is required.
- Controlled access to a single object is necessary.
