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

Description

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. Imposing such a constraint can lead to several problems. Future developers may forget to call the superclass causing untold bugs and system errors. Additionally, it requires anyone using the interface to have an understanding of the inner workings of the superclass. Ideally, they would only need to understand the public interface. Finally, if the superclass expects specific actions from the subclass, it may not perform well (or at all) if those actions aren't performed as expected.

A better approach to obtaining the desired functionality would be to use the Template Method pattern. Here the superclass would include a public method and define a separate method (often called a hook method) for the subclass to override. The superclass method would then call the hook method. The hook method can either be an abstract method in the superclass and fully implemented in the subclass, or have some basic functionality in the superclass and augmented in the superclass. Either way the subclass does not have to worry about calling the superclass.

Example

Let's say we have a class registration framework with an EventHandler superclass. The EventHandler is used to process all "transactions" - administrators adding classes, students registering for classes, students dropping classes, etc. It has to do some basic setup and housekeeping functions (checking availability, permissions, etc.) before the registration event can be processed. Our original code for a student registering for a class might be something like the following.

 public class EventHandler ...
   public void handle (RegistrationEvent e) {
     setup(e);
   }

 public class StudentClassRegistrationHandler extends EventHandler...
   public void handle(RegistrationEvent e) {
     super.handle(e);
     RegisterStudent(e);
   }

The method StudentClassRegistrationHandler must call super.handle() before it can begin its task of registering the student. If we refactor this code using the Template Pattern, we could get the following code:

 public class EventHandler ...
   public void handle (RegistrationEvent e) {
     setup(e);
     doAction(e);
   }
   protected void doAction(RegistrationEvent e) {
   }

  public class StudentClassRegistrationHandler extends EventHandler ...
    protected void doAction(RegistrationEvent e) {
     RegisterStudent(e);  }

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>