Year: 2017

This is a class diagram for the state design pattern

Purpose

Ties object circumstances to its behavior, allowing the object to behave in different ways based upon its internal state.

Use When

• The behavior of an object should be influenced by its state.
• Complex conditions tie object behavior to its state.
• Transitions between states need to be explicit.

This is a UML class diagram for the observer design pattern.

Purpose

Lets one or more objects be notified of state changes in other objects within the system.

Use When

• State changes in one or more objects should trigger behavior in other objects
• Broadcasting capabilities are required.
• An understanding exists that objects will be blind to the expense of notification.

This is a UML class diagram example for the Mememo design pattern.

Purpose

Allows for capturing and externalizing an object's internal state so that it can be restored later, all without violating encapsulation.

Use When

• The internal state of an object must be saved and restored at a later time.
• Internal state cannot be exposed by interfaces without exposing implementation.
• Encapsulation boundaries must be preserved.

This is a class diagram example for the Mediator design pattern.

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 When

• Communication between sets of objects is well defined and complex.
• Too many relationships exist and common point of control or communication is needed.

This is a class diagram example for the Iterator design pattern.

Purpose

Allows for access to the elements of an aggregate object without allowing access to its underlying representation.

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

This is a class diagram example for the Interpreter design pattern.

Purpose

Defines a representation for a grammar as well as a mechanism to understand and act upon the grammar.

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

This is a UML class diagram example for the Command design pattern.

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

This is a UML class diagram example for the Chain of Responsibility design pattern.

Purpose

Gives more than one object an opportunity to handle a request by linking receiving objects together.

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

This is a UML class diagram example for the Proxy design pattern.

Purpose

Allows for object level access control by acting as a pass through entity or a placeholder object.

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

This is a UML class diagram example for the Flyweight design pattern.

Purpose

Facilitates the reuse of many fine grained objects, making the utilization of large numbers of objects more efficient.

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