Short summary of design patterns — Part III. Behavioral patterns.

Design patterns

I want to show you a simple catalog of design patterns for object oriented programming that are described in the great book Design Patterns. Elements of Reusable Object-Oriented Software.

In previous parts of that series I’ve presented creational patterns and structural patterns.

Part III. Behavioral Patterns

Behavioral patterns are about how problems are solved and how responsibilities are splitted between objects. They are more about comunnication than structure.

Chain of Responsibility
Decouple sender of a request from its receiver by giving more than one object a chance to handle that request.
Use when: more than one object can handle a request and that information is known in runtime.

Command
Encapsulate a request as an object.
Use when: you have a queue of requests to handle or you want to log them. Also when you want to have “undo” action.

Interpreter
Interprets a sentence in a given language by using representation of a grammar in that language.
Use when: you want to interpret given language and you can represent statements as an abstract syntax trees.

Iterator
Provide a way to access elements of an aggregated objects sequentially without exposing how they are internally stored.
Use when: you want to access object’s content without knowing how it is internally represented.

Mediator
Define an object that knows how other objects interact. It promotes loose coupling by removing direct references to objects.
Use when: a set of objects communicate in structured by complex ways.

Memento
Capture external state of an object if there will be a need to restore it without violating encapsulation.
Use when: you need to take a snapshot of an object.

Observer
When one object changes state, all its dependents are notified about that fact.
Use when: a change to one object requires changing others.

State
Object is allow to change its behaviour when its internal state changes. It looks like the object is changing its class.
Use when: the object’s behaviour depends on its state and its behaviour changes in run-time depends on that state.

Strategy
It lets to algorithm to be independent from clients that use it.
Use when: you have many classes that differ in their behaviour. Strategies allow to configure a class with one of many behaviours.

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.
Use when: you have to define steps of the algorithm once and let subclasses to implement its behaviour.

Visitor
Represent an operation to be performed on the elements of the structure. It lets you to define new operations without changing the classes of the elements.
Use when: an object structure includes many classes and you want to perform an operations on the elements of that structure that depend on their classes.
I wrote a blog post about visitor pattern in Ruby.