Design Patterns are a software engineering concept describing recurring solutions to common problems in software design. The authors Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides are often referred to as the GoF, or Gang of Four. The site explores the capabilities and pitfalls of object-oriented programming and describes several software design patterns. Part of the appeal of design patterns is that they can be used uniformly over many different languages and syntaxes. The basic structure stays the same; only the details change. It is easy to take a pattern implemented in Java and convert it to C++. Historically the Design Patterns
  1. have been locked in the heads of the experts or
  2. buried deep in the source code.
What is required is a principled means of extracting, documenting, conveying, applying, and preserving this design experience without undue time and effort.
Design Patterns
Design Patterns - Glossary
Design Patterns Course Introduction
Three Design Pattern Types   Why Use Design Patterns - Quiz Design Pattern Scope
  Design Pattern Benefits
 
 
Singleton Design Pattern Singleton Intent/Motivation Consequences Effects Singleton Singleton Pattern - Quiz
Singleton Pattern
 
Common Creational Patterns Factory Method - Exercise
 
Structural Design Patterns Structural Design Pattern Common Structural Patterns
 
 
Behavioral Design Patterns Mediator Chain of Responsibility Strategy Pattern
Using Design Patterns - Quiz How To Choose Design Pattern
 


Behavioral Patterns
Chain of Responsibility Command Pattern    

Creational Patterns
Abstract Factory Factory Method Pattern     

Structural Patterns
Adapter Pattern Bridge Pattern    


Behavioral, Creational, Structural
Behavioral, Creational, Structural
A pattern must explain why a particular situation causes problems and why the proposed solution is considered a good one. Common design problems arise from "conflicting forces" such as the conflict between breaking the speed of sound and preventing the aircraft from disintegrating. These values, used by the pattern's author to determine which solution is "best", must also be documented within the pattern. A pattern must also explain when it is applicable. Since two houses may be very different from one another, a design pattern for houses must be broad enough to apply to both of them, but not so vague that it doesn't help the designer make decisions. The range of situations in which a pattern can be used is called its context. Some examples might be "all houses", "all two-story houses", or "all places where people spend time". The context must be documented within the pattern.

This website is about design patterns that describes simple and elegant solutions to specific problems in object-oriented software design. Design patterns capture solutions that have developed and evolved overtime and they are not the designs people tend to generate initially. They reflect untold redesign and recoding as developers have struggled for greater reuse and flexibility in their software. The origins of object oriented design is debated, but the first languages that supported OO were Simula and SmallTalk. The site includes code examples in C++ and Java. Design patterns capture these solutions in a succinct and easily applied form.
The design patterns do not require.
  1. unusual language features or
  2. amazing programming techniques.
All can be implemented in standard object-oriented languages, though they might take a little more effort than ad hoc solutions.
Once you understand the design patterns and have had a revelation with them, you will not think about object-oriented design in the same way and will have insights that can make your own designs more flexible, modular and reusable.