This is a UML class diagram example for the template method pattern.

Purpose

Identifies the framework of an algorithm, allowing implementing classes to define the actual behavior.

Use When

• A single abstract implementation of an algorithm is needed.
• Common behavior among subclasses should be localized to a common class.
• Parent classes should be able to uniformly invoke behavior in their subclasses.
• Most or all subclasses need to implement the behavior.

This is a class diagram for strategic design pattern.

Purpose

Defines a set of encapsulated algorithms that can be swapped to carry out a specific behavior.

Use When

• The only difference between many related classes is their behavior.
• Multiple versions or variations of an algorithm are required.
• Algorithms access or utilize data that calling code shouldn't be exposed to.
• The behavior of a class should be defined at runtime.
• Conditional statements are complex and hard to maintain.

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.