A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context. 

Templates that describe a design alternatives 

"Peter Norvig found that 16 of the 23 patterns in Design Patterns were 'invisible or simpler' in Lisp."

- Paul Graham, revenge of the nerds
http://www.paulgraham.com/icad.html

Adds behavior to an individual object rather than to an entire class of objects—this allows us to change the behavior of an existing class.

To attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

Decorator class diagram

Defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

Define an algorithm in abstract terms so it can be implemented in several different ways, and to allow it to be injected into clients so it can be used across several different clients.

Strategy class diagram

Command encapsulates an action along with the information needed to perform it.

To encapsulate a request as an object, thereby  letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

Command class diagram

The Client is responsible for creating a ConcreteCommand and setting its Receiver

The Invoker holds a command and at some point asks the command to carry out a request by calling its execute() method

Command declares an interface for all commands. A command is invoked through its execute() method, which asks a receiver to perform an action

void execute() {

        receiver.action();

}

The Receiver knows how to perform the work needed to carry out the request. Any class can act as a Receiver

The ConcreteCommand defines a binding between an action and a Receiver. The Invoker makes a request by calling execute() and the ConcreteCommand carries it out by calling one or more actions on the Receiver

The execute method invokes the action(s) on the receiver needed to fulfill the request

When you want to add capabilities to a composite of objects and encapsulation is not important.

To encapsulate an action to be performed on a data structure in a way that allows the addition of new operations to the data structure without having to modify it.

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
Encapsulate the core (or common or engine) components in a Subject abstraction, and the variable (or optional or user interface) components in an Observer hierarchy.
The "View" part of Model-View-Controller.

Encapsulates the construction of a product and allow it to be constructed in steps

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

Solution to Telescoping Constructor anti-pattern

Create an immutable object using a friendly syntax 

Telescopic constructor anti pattern

Refactor in conjunction with parameter object