Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context.

Design patterns vary in their granularity and level of abstraction. Because there are many design patterns, we need a way to organize them. Patterns can have either Creation, Structural, or Behavioral purpose.

Scope		Purpose
		Creational	Structural	Behavioral
	Class	Factory Method	Adapter	Interpreter
	Class			Template Method
	Object	Abstract Factory	Adapter	Chain of Responsibility
		Builder	Bridge	Command
		Prototype	Composite	Iterator
		Singleton	Decorator	Mediator
			Façade	Memento
			Flyweight	Observer
			Proxy	State
				Strategy
				Visitor

Design pattern space

A) Creational Pattern

Creational design patterns abstract the instantiation process. They help make a system independent of how its objects are created, composed and represented.

1) Abstract Factory

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

2) Builder

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

3) Factory Method

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

4) Prototype

Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.

5) Singleton

Ensure a class only has one instance, and provide a global point of access to it.

B) Structural Pattern

Structural patterns are concerned with how classes and objects are composed to form larger structures.Structural class patterns use inheritance to compose interfaces or implementations.

1) Adapter

Aka: Wrapper

Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

2) Bridge

Aka: Handle/Body

Decouple an abstraction from its implementation so that the two can vary independently.

3) Composite

Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

4) Decorator

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

5) Façade

Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

6) Flyweight

Use sharing to support large numbers of fine-grained objects efficiently.

7) Proxy

Provide a surrogate or placeholder for another object to control access to it.

Note : Composite versus Decorator versus Proxy

Composite and Decorator have similar structure diagrams, reflecting the fact that both rely on recursive composition to organize an open-ended number of objects. The similarity ends at recursive composition, again because of differing intents.

Decorator is designed to let you add responsibilities to objects without subclassing. It avoids the explosion of subclasses that can arise from trying to cover every combination of responsibilities statically. Composite focuses on structuring classes so that many related objects can be treated uniformly, and multiple objects can be treated as one.

In the Proxy pattern, the subject defines the key functionality, and the proxy provides (or refuses) access to it. In Decorator, the component provides only part of the functionality, and one or more decorators furnish the rest.

C) Behavioural Patterns

Behavioural patterns are concerned with algorithms and the assignment of responsibilities between objects. These patterns characterize complex control flow that's difficult to follow at run-time.

They shift your focus away from flow of control to let you concentrate just on the way objects are interconnected.

1) Chain of Responsibility

Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.

2) Command

Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undo-able operations.

Aka: Action, Transaction

3) Interpreter

Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.

4) Iterator

Provide a way to access the elements of an aggregate objects equentially without exposing its underlying representation.

Aka: Cursor

5) Mediator

Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.

6) Memento

Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.

Aka: Token

7) Observer

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Aka: Dependents, Publish-Subscribe

8) State

Allow an object to alter its behavior when it’s internal state changes. The object will appear to change its class.

9) Strategy

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

Aka: Policy

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

11) Visitor

Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

Credits : Gang of Four

(Tech-novate)

Object Oriented Programming - Design Patterns