CSC/ECE 517 Fall 2011/ch7 7d rt

AntiPatterns in Software Development

Introduction

The term antipattern was coined by Andrew Koenig<ref name = koenig/>, in 1995. His inspiration was 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<ref name = ap/>. 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 a alternate, preferred solution that is proven and repeatable.

Through the years the concept of antipatterns 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:

1. Name so that they can be identified.
2. A description of why the bad solution might be attractive.
3. An explanation of how that solution is bad long-term.
4. Suggestions for other patterns that provide better solutions.

There are several catalogs of antipatterns available as well as a number of books that address the topic. Below we will explore a few of the more common antipatterns.

AntiPatterns

Call Super

We are all familiar with the concept of inheritance in object-oriented programming where a subclass takes on the properties and actions of a superclass. The subclass can then override the methods of the superclass either replacing or augmenting the functionality provided in the superclass. The call super antipattern requires subclasses to override methods of the super class and then call back the overridden method at some point. This requirement may stem from the fact that the superclass does some set up operations that cannot be done in the subclass or if the subclass is expanding the superclass task rather than replacing it.

Calling a superclass method from a subclass is not in general a bad practice, but requiring it to do so is.

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> <ref name = ap> Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Thomas J. Mowbray, Theresa Hudson (ed) (1998). AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. </ref>

</references>