Object-Orientation - Design Patterns in Software Development

Common problems and their solutions.

  1. Overview
  2. History
  3. Criticisms
  4. Creational
  5. Structural
  6. Behavioral
  7. Conclusions



Design Patterns are good quality re-usable solutions to common problems.

In other words, Design Patterns represent a set of best practices for particular contexts.

What they offer

Design Patterns describe a particular design problem.

They do not prescribe a solution. Rather, they indicate a set of values to guide the designer toward a solution to the problem that is best for their particular situation.

Nature in Flux

There is no complete set of design patterns.



Seneca The Younger spoke of the value of abstract patterns versus their concrete implementations circa 65 AD in his letter to his friend, Lucilius, now referred to as “On Sharing Knowledge”:

The way is long if one follows precepts, but short and helpful, if one follows patterns.


A Pattern Language, by Christopher Alexander, Sara Ishikawa, Murray Silverstein

Architecture (continued)

Agricultural Valley design pattern, from A Pattern Language

Architecture (continued)

Small Work Groups design pattern, from A Pattern Language


Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides


Language Flaws

A common criticism of Design Patterns is that their necessity indicates flaws in the programming language they are designed for.


Another criticism holds that Design Patterns can lead to overly complex and verbose code, when a simpler unpatterned solution might be simpler and easier to maintain.



A fully initialized instance to be copied or cloned.

Useful when the setup of an object is time/resource consuming, and you do not want to repeat it more than once, if possible.


Separates object construction from its representation.

The builder pattern provides a simple interface to create an object that actually has a complex structure.

Useful when there’s a complex object structure that is complicated to build.


A class of which only a single instance is allowed to exist.

Useful when you need only one object of that class to exist.



An object representing another object. It’s an imposter! Hides the complexity of the object it represents.

Example: credit card is a proxy for a bank account.


A single class that represents the entire subsystem.

Useful for web applications. Reducing network calls. Reduces coupling (bewteen web layer and back-end). Helps rollback all steps if one fails.


Adds responsibility to objects dynamically. Makes it easy to add behavior at runtime.


Chain of responsibility

A way of passing a request between a chain of objects.

A message passes through a series of objects until one of them is able to handle it, at which point is doesn’t get passed any further.


Sequentially access the elements in a collection.

Useful when the internal representation of a collection of objects isn’t important, and you simply want to be able iterate through the objects in the collection.


A way of notifying a change to an object to a number of other objects. Objects can be registered to receive notifications.

Situation: When one of the objects changes, it needs to let several of the other objects know.


This has been a brief, but inspirational introduction to design patterns.