Antipatterns
(Fixed broken link) |
JaninaVoigt (Talk | contribs) (→Antipatterns) |
||
Line 1: | Line 1: | ||
== Antipatterns == | == Antipatterns == | ||
+ | |||
+ | 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]] | "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]] | "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 {{Ref|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 antipatterns 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 antipatterns 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" ({{Ref|1}}) in 1998. | |
− | This | + | This book has been followed by others, e.g.: |
* ''J2EE Antipatterns'', by Bill Dudney, et al | * ''J2EE Antipatterns'', by Bill Dudney, et al | ||
* ''Antipatterns in Project Management'', by William J. Brown | * ''Antipatterns in Project Management'', by William J. Brown | ||
Line 15: | Line 21: | ||
It might be argued that the first antipatterns were Dilbert cartoons. | It might be argued that the first antipatterns were Dilbert cartoons. | ||
+ | |||
+ | 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 {{Ref|3}}) | ||
+ | |||
+ | There are many different anti pattern categories including: | ||
+ | * Organizational anti-patterns | ||
+ | * Project management anti-patterns | ||
+ | * Analysis anti-patterns | ||
+ | * Software design anti-patterns, and | ||
+ | * [[Object-oriented design anti-patterns]] | ||
Antipatterns are closely related to [[Code smells]] and [[Design maxims]] that start with Avoid... or Beware... | Antipatterns 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). | [[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 {{Ref|2}} or {{Ref|3}}. | ||
+ | |||
+ | ==References== | ||
+ | #{{Note|1}}William Brown, Raphael Malveau, Hays McCormick, and Thomas Mowbray. Anti Patterns: refactoring software, architectures, and projects in crisis. John Wiley and Sons, 1998. | ||
+ | #{{Note|2}} http://c2.com/cgi/wiki?AntiPatternsCatalog | ||
+ | #{{Note|3}} http://en.wikipedia.org/wiki/Anti-pattern | ||
== See also == | == See also == |
Revision as of 06:43, 18 July 2009
Antipatterns
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 antipatterns 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.
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])
There are many different anti pattern categories including:
- Organizational anti-patterns
- Project management anti-patterns
- Analysis anti-patterns
- Software design anti-patterns, and
- Object-oriented design anti-patterns
Antipatterns 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].
References
- ^William Brown, Raphael Malveau, Hays McCormick, and Thomas Mowbray. Anti Patterns: refactoring software, architectures, and projects in crisis. John Wiley and Sons, 1998.
- ^ http://c2.com/cgi/wiki?AntiPatternsCatalog
- ^ http://en.wikipedia.org/wiki/Anti-pattern