CSC/ECE 517 Fall 2011/ch7 7d rt: Difference between revisions
| Line 5: | Line 5: | ||
The term ''antipattern'' was coined by Andrew Koenig<ref name = koenig/>, in 1995. He was inspired by a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work. | The term ''antipattern'' was coined by Andrew Koenig<ref name = koenig/>, in 1995. He was inspired by a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work. | ||
Koenig believed that the same philosophy should be applied to software development. As he studied the book ''Design Patterns'' presented by the GoF<ref name = gof/>, he felt that it was just as important to identify potential | Koenig believed that the same philosophy should be applied to software development. As he studied the book ''Design Patterns'' presented by the GoF<ref name = gof/>, he felt that it was just as important to identify potential pitfalls as well as positive practices. He named these non-solutions ''antipatterns''. He defined an ''antipattern'' as "just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one." <ref name = koenig/> | ||
In 1998, a different group of four expanded on this idea publishing '''''AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis'''''. The book identified antipatterns from three different viewpoints: the software developer, the software architect and the software manager. The authors used two criteria to distinguish antipatterns: | |||
* It was a frequent occurrence, that initially seemed to be beneficial, but ultimately was not and | |||
* There is an preferred, alternate solution that is proven and repeatable | |||
Through the years the concept has been further extended to apply to additional areas of software development as well as areas outside the realm of programming. This article will address software development antipatterns. | |||
Through the years the concept has been further | |||
Just like patterns, antipatterns have certain elements. They include: | Just like patterns, antipatterns have certain elements. They include: | ||
Name so that they can be identified. | # Name so that they can be identified. | ||
A description of why the bad solution might be attractive | # A description of why the bad solution might be attractive. | ||
An explanation of how that solution is bad long-term | # An explanation of how that solution is bad long-term. | ||
Suggestions for other patterns that provide better solutions | # Suggestions for other patterns that provide better solutions. | ||
==AntiPatterns== | ==AntiPatterns== | ||
Revision as of 16:25, 26 November 2011
AntiPatterns in Software Development
Introduction
The term antipattern was coined by Andrew Koenig<ref name = koenig/>, in 1995. He was inspired by a story told about Thomas Edison's many failed attempts to find a suitable material for the filament of a light bulb. When asked if he was discouraged, Edison replied that indeed he was not; he now knew hundreds of items that wouldn't work.
Koenig believed that the same philosophy should be applied to software development. As he studied the book Design Patterns presented by the GoF<ref name = gof/>, he felt that it was just as important to identify potential pitfalls as well as positive practices. He named these non-solutions antipatterns. He defined an antipattern as "just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one." <ref name = koenig/>
In 1998, a different group of four expanded on this idea publishing AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. The book identified antipatterns from three different viewpoints: the software developer, the software architect and the software manager. The authors used two criteria to distinguish antipatterns:
- It was a frequent occurrence, that initially seemed to be beneficial, but ultimately was not and
- There is an preferred, alternate solution that is proven and repeatable
Through the years the concept has been further extended to apply to additional areas of software development as well as areas outside the realm of programming. This article will address software development antipatterns.
Just like patterns, antipatterns have certain elements. They include:
- Name so that they can be identified.
- A description of why the bad solution might be attractive.
- An explanation of how that solution is bad long-term.
- Suggestions for other patterns that provide better solutions.
AntiPatterns
Call Super
Base Beans
The Blob
Golden Hammer
Conclusions
Resources
References
<references> <ref name = koenig> Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). The patterns handbook: techniques, strategies, and applications. Cambridge, U.K.: Cambridge University Press. p. 387. </ref> <ref name = gof> Design Patterns by Gang of Four</ref> </references>