Design Patterns (gang-of-four)

Creational Patterns

Abstract Factory (87)   Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

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

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

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

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

Structural Patterns

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

Bridge (151)   Decouple an abstraction from its implementation so that the two can vary independently.

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

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

Facade (185)   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.

Flyweight (195)   Use sharing to support large numbers of fine-grained objects efficiently.

Proxy (207)   Provide a surrogate or placeholder for another object to control access to it.

Behavioral Patterns

Chain of Responsibility (223)   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.

Command (233)   Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

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

Iterator (257)   Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

Mediator (273)   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.

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

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

State (305)   Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.

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

Template Method (325)   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.

Visitor (331)   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.

Head First Design Patterns

Our focus is on the core patterns that matter from the original GoF patterns, and making sure that you really, truly, deeply understand how and when to use them. You will find a brief look at some of the other patterns (the ones you're far less likely to use) in the appendix.

The GoF patterns discussed in detail:

The GoF patterns briefly introduced:

Design Principles

Sample chapter: Decorator pattern

Poster Web page

Book's Web page

Publisher's Web page

Design Patterns Explained

A customer review @ Amazon ... "I picked up this book after reading through the original GoF Design Patterns. Although they discuss similar topics and this book refers to the GoF book quite frequently, I wouldn't necessarily associate the two with each other despite having similiar book titles. There isn't much code or elaborate examples in this book, but it is easily read and understood by any level of programmer. In my opinion though you should probably read this book first before you read the GoF book despite this one actually being the one that is supposed to explain the other. To me it felt more like a synopsis and is too brief in many places. More or less it makes a good introduction into design patterns, but it is not the book that will give you a full understanding of patterns."

The authors do not introduce all 23 GoF patterns. Those discussed are:

UML and GRASP Patterns

The critical design tool for software development is a mind well educated in design principles. It is not the UML or any other technology.  — Craig Larman

GRASP (General Responsibility Assignment Software Patterns) are guidelines for assigning responsibility to classes and objects in OO design. They are really a mental toolset, a learning aid to help in the design of object oriented software. The patterns and principles specified by GRASP are ...

Information Expert
Look at a given responsibility, determine the information needed to fulfill it, and then determine where that information is stored. Information Expert will lead to placing the responsibility on the class with the most information required to fulfill it.
Creation of objects is one of the most common activities in an object-oriented system. Which class is responsible for creating objects is a fundamental property of the relationship between objects of particular classes. In general, a class B should be responsible for creating instances of class A if one, or preferably more, of the following apply:
Assign the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. It should delegate to other objects the work that needs to be done; it coordinates or controls the activity. It should not do much work itself.
Low Coupling
Refers to the degree of direct knowledge that one class has of another. This supports: low dependency between classes, low impact in a class due to changes in other classes, and high reuse potential.
High Cohesion
Keep objects appropriately focused, manageable and understandable. High cohesion is generally used in support of Low Coupling. High cohesion means that the responsibilities of a given element are strongly related and highly focused. Breaking programs into classes and subsystems is an example of activities that increase the cohesive properties of a system. Alternatively, low cohesion is a situation in which a given element has too many unrelated responsibilities. Elements with low cohesion often suffer from being hard to comprehend, hard to reuse, hard to maintain and adverse to change.
Promote common interface to a base class, and bury peculiar implementation details in derived classes. The client of the abstraction hierarchy should then couple itself only to the base class. Another way this has been descirbed is: the responsibility of defining the variation of behaviors based on type is assigned to the types for which this variation happens.
Pure Fabrication
Invent a class that does not represent a concept in the problem domain. It is conceived to achieve low coupling, high cohesion, and reuse potential across the classes that represent domain concepts.
Assign the responsibility of mediation between two elements to an intermediate object. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-View-Controller pattern.
Protected Variations
Protect elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.