From CSSEMediaWiki
Revision as of 03:23, 25 November 2010 by WikiSysop (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

While design patterns are often seen as good design solutions to a common problem, anti-patterns are the opposite: bad solutions to a common problem.

An anti-pattern is something that looks like a good idea, but which backfires badly when applied. –-Jim Coplien
In the old days, we used to just call these 'bad ideas'. The new name is much more diplomatic. –-Ward's wiki

Anti-patterns usually describe designs that look like a good idea at first but have negative effects when used. Because they look like an attractive solution, developers may be easily tempted to use them. To avoid this, they have been documented just like "positive" design patterns (in [1] for example).

The documentation of an anti-pattern will often tell you why the bad solution looks good, what negative effects it causes if it's used and what positive pattern should be applied to solve the problem instead.

The idea of anti-patterns is a little controversial in the patterns community. Some people don't like the idea of cataloging bad ideas, because there are infinitely many of them, among other reasons. Over time, however, they seem to have been increasingly accepted.



The term Anti-Pattern was first coined in 1995 by Andrew Koenig who was inspired by the Gang of Four design patterns book. Anti-patterns became more popular after the release of the book "Anti Patterns: refactoring software, architectures, and projects in crisis" ([1]) in 1998.

This book has been followed by others, e.g.:

  • J2EE Antipatterns, by Bill Dudney, et al
  • Antipatterns in Project Management, by William J. Brown
  • Anti-Patterns and Patterns in Software Configuration Management, by William J. Brown

It might be argued that the first antipatterns were Dilbert cartoons.

Clarification of the definition

The authors of the original Anti Patterns book distinguish an anti-pattern from a simple bad practice or habit and state that two key-elements need to be present for an actual anti-pattern:

  • "Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results, and"
  • "A refactored solution that is clearly documented, proven in actual practice and repeatable." (from [3])

Types of antipatterns

There are many different anti-pattern categories including:

Relations and Known Antipatterns

Anti-patterns are closely related to Code smells and Design maxims that start with Avoid... or Beware...

Big ball of mud is a more thoughtful antipattern (although it isn't usually described as one).

For a long list of common anti-patterns, see [2] or [3].

Example and Formatting

Example of a Antipattern

Name: Broken window

Problem: You need to go to Wal's exam, but you forgot the key inside the car and the car is locked. How do I get at the University on time?

Context: I locked the keys inside the car.

Solution: Break the window, get in the car and drive to the University.

We have the components, the problem to achieve my goal having the keys inside the car and inaccessible and the bad solution to break the window to be at the University on time. This is a anti-pattern example, breaking the window allows you to do what you need at that time, get to the University on time, but the problem is your loss, the cost of getting the window fixed.

In William Brown 1998 (pp. 57-60), they describe a model for accurately and completely describing an antipattern. It consists of the following components:

  • Name
  • Also known as
  • Most frequent scale - the architectural level where this pattern occurs
  • Refactored solution name
  • Refactored solution type - Software, Technology, Process or Role
  • Root causes
  • Unbalanced forces
  • Anecdotal evidence (optional)
  • Background (optional)
  • General form of antipattern
  • Symptoms and consequences
  • Typical causes
  • Known exceptions
  • Refactored solutions
  • Variations (optional)
  • Example
  • Related solutions
  • Applicability to other viewpoints/scales


  1. ^William Brown, Raphael Malveau, Hays McCormick, and Thomas Mowbray. Anti Patterns: refactoring software, architectures, and projects in crisis. John Wiley and Sons, 1998.
  2. ^
  3. ^

See also

Personal tools