Antipatterns

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
m (Added some section headings)
Line 1: Line 1:
== Anti-patterns ==
 
 
 
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.
 
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.
  
Line 12: Line 10:
  
 
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 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.
 +
 +
== Origins ==
  
 
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" ({{Ref|1}}) in 1998.  
 
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" ({{Ref|1}}) in 1998.  
Line 22: Line 22:
 
It might be argued that the first antipatterns were Dilbert cartoons.
 
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:
 
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:
  
Line 27: Line 28:
 
*"A refactored solution that is clearly documented, proven in actual practice and repeatable." (from {{Ref|3}})
 
*"A refactored solution that is clearly documented, proven in actual practice and repeatable." (from {{Ref|3}})
  
 +
== Types of antipatterns ==
 
There are many different anti-pattern categories including:
 
There are many different anti-pattern categories including:
 
* Organizational anti-patterns
 
* Organizational anti-patterns
Line 33: Line 35:
 
* Software design anti-patterns, and
 
* Software design anti-patterns, and
 
* [[Object-oriented design anti-patterns]]
 
* [[Object-oriented design anti-patterns]]
 +
 +
== Relations and Examples ==
  
 
Anti-patterns are closely related to [[Code smells]] and [[Design maxims]] that start with Avoid... or Beware...
 
Anti-patterns are closely related to [[Code smells]] and [[Design maxims]] that start with Avoid... or Beware...

Revision as of 00:06, 14 September 2009

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. –-James Copelien
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.

Contents

Origins

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 Examples

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 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 achive 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 Univeristy on time, but the problem is your loss, the cost of getting the window fixed.

References

  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. ^ http://c2.com/cgi/wiki?AntiPatternsCatalog
  3. ^ http://en.wikipedia.org/wiki/Anti-pattern

See also

Personal tools