Software Patterns

Fundamental to any science or engineering discipline is a common vocabulary for expressing its concepts, and a language for relating them together. The goal of patterns within the software community is to create a body of literature to help software developers resolve recurring problems encountered throughout all of software development. Patterns help create a shared language for communicating insight and experience about these problems and their solutions. Formally codifying these solutions and their relationships lets us successfully capture the body of knowledge which defines our understanding of good architectures that meet the needs of their users. Forming a common pattern language for conveying the structures and mechanisms of our architectures allows us to intelligibly reason about them. The primary focus is not so much on technology as it is on creating a culture to document and support sound engineering architecture and design.

(Brad Appleton)


The concept of a pattern language, derived from timeless entities called patterns, comes from “A Pattern Language: Towns, Buildings, Construction”, a 1977 book on architecture, urban design, and community livability. It was authored by Christopher Alexander, Sara Ishikawa and Murray Silverstein of the Center for Environmental Structure of Berkeley, California, with writing credits also to Max Jacobson, Ingrid Fiksdahl-King and Shlomo Angel.

In 1995 Gamma, Helm, Johnson, and Vlissides published “Design Patterns: Elements of Reusable Object-Oriented Software.” It contains the 23 creational, structural, and behavioral software design patterns listed below.

  • Creational Patterns
    • abstract factory
    • builder
    • factory method
    • prototype
    • singleton
  • Structural Patterns
    • adapter
    • bridge
    • composite
    • decorator
    • façade
    • flyweight
    • proxy
  • Behavioral Patterns
    • chain of responsibility
    • command
    • interpreter
    • iterator
    • mediator
    • memento
    • observer
    • state
    • strategy
    • template method
    • visitor

In 2001 Sun Microsystems authors Deepak Alur, John Crupi and Dan Malks published “Core J2EE Patterns: Best Practices and Design Strategies.” It contained the 15 design patterns shown in the following diagram.

Pattern Sources

There are many software patterns that have been identified and documented. Beyond the ones described above they can be found in many books and articles. Most development organizations have their own standardized patterns that they use to encourage common enterprise-wide design approaches to the same types of problems. Several web site pattern collections are listed below.

Pattern Taxonomy

There are three software pattern categories. They are:

  • Architecture
  • Design
  • Implementation

Pattern Template

Patterns are documented using the following template:

  • Problem
  • Context
  • Forces
  • Solution
  • Resulting Context
  • Examples
  • Rationale
  • Related Patterns
  • Known Uses

How Do I Use Patterns

Most developers are comfortable using industry standard design and implementation patterns. This is because there is a pattern that can be used to describe most good development practices. As you learn more and more about existing patterns and compare them to your development you will discover better ways to solve many design issues. You will also start to use the pattern names to describe your design to others as a matter of expediency and shorthand.

However, many organizations and development teams struggle with the adoption of patterns. I have seen this happen many times when patterns are used by architectural teams as a method of governance and standardization. The issue is not whether patterns can contribute to good governance and standardization. The issue is the order in which patterns and pattern usage are applied.

When an organization creates an architectural initiative to define all of the approved architectural and design patterns up front you are wasting both time and effort. As in real life, organizational preferred patterns should come from successful implementations within the organization. See what problems exist within your organization, identify the best solutions to those problems, and then extract those as patterns for future implementations. You don’t need a lot of patterns. I used like maybe 3 design patterns for the middleware solution of a $60m implementation project that integrated 6 major commercial off the shelf systems.