CSC/ECE 517 Fall 2011/ch7 7d df

Design Patterns

Introduction

In Software Engineering, an Anti-Pattern is a type of pattern that, at first, may appear to solve a problem but ends up hindering it in the long run. While a pattern can be looked at as a solution to a problem, an anti-pattern is considered a bad solution to a problem[1]. The name anti-patern was coined by Andrew Koenig in response to the book, Design Patterns, by Gang of Four. However, the term did not become commonplace until after the book, AntiPatterns, came out. In the book, the authors had outlined a few patterns that were fairly common in the workplace that they saw as an anti-pattern. An anti-pattern is not to be confused with bad programming habits. There are two main distinctions between an anti-pattern and bad programming. First, for a bad idea to be an anti-pattern, it has to have some sort of structure and is reusable and second, the anti-pattern has to have a well documented, correct solution. Anti-Patterns can be found not only in programming but a number of different areas in the design process. Because of this, anti-patterns can fall into different groups such as Organizational, Project Management, Software Design, and Programming. Listed below are a select few of the many Anti-Patterns that exist [2].

Organizational

Organizational anti-patterns are those that deal with how the team working on the project is organized and managed. A good example of these types of patterns is the Cash Cow.

Cash Cow

A Cash Cow is a product that makes up the majority of a companies profits. The problem with Cash Cows is they may be making a great deal of money for the money now, but may later fall out of popularity due to newer or better technology. The sheer popularity of the product can sometimes hinder the development of newer alternatives. Take for example the company RIM, the maker of the BlackBerry line of smartphones. A couple years ago RIM's BlackBerry smartphones were considered cash cows. RIM was dominating the market. Over the years, new players have come into the market with revolutionary ideas and have been slowly eating away at RIMs marketshare. During this same time, BlackBerry smartphones have changed little. Their management had been blinded by the sheer success of their products that they allowed others to come in and take that success away from them [3].

Project Management

Project Management anti-patterns are anti-patterns that deal with how the programmers and the whole team in general work together to complete the project at hand. Some examples of this are Over Engineering and Software Bloat.

Over Engineering

Over Engineering is when a product is made more complex than is practical. This results in a waste of time and resources. For instance, a push lawnmower with 100 HP would be a product of over engineering. A lawnmower with a tenth of that power would work just as well without all the time and money spent upping the Horse Power [4].

Software Bloat

Software Bloating happens when after every new release of a piece of software, more and more features are added that are not necessarily used by the consumer or stray from the original purpose of the program. These features use more computer resources and can ultimately slow down the program. Also, not every user will use all of the features, causing in some cases unnecessary slowdown of the program. A good example of Software Bloating is Apple's iTunes. iTunes was originally created to simply download and play music. Now, iTunes can do so much more to the point where the features are detracting from the original functions. A good alternative to software bloating is the use of plugins. Plugins add extra functionality to a program without forcing the user to have it. This way a user can pick and choose which extra features he or she wants [5].

Software Design

Software design anti-patterns are anti-patterns that deal with the overall design of a program. They deal more with how the object in a program fit together rather than the actual code itself. Some examples of Software Design anti-patterns are BaseBean and Call Super.

BaseBean

A BaseBean is a class where concrete entities have subclassed it. As you may know from class, subclassing does not always exhibit good program design. Subclassing causes the child class to rely too heavily on the superclass. If the super class were to change, it could break something in the subclass. A class should not subclass another class just because there is similar code. Rather, the classes should interact using delegation [6].

Call Super

Call Super is similar to BaseBean in which one class subclasses another. The different is, in Call Super, the superclass requires the subclass to override a method in order for it to function. The fact that this is required makes this an anti-patern. The solution to this problem is to use the Template Method Pattern. The Template Method pattern separates the superclass method into two distinct methods. The first method executes all of the needed code by the subclass and then delegates the part that needs to be subclassed into an abstract method. That way the superclass is able to separate out the information that needs to be accessed by the subclass and the method that needs to be overridden [7]. Here is an example:

       class super{
           ...
           public void doSomething(){
               //perform initialization
           }
       }

       class sub extends super{
           ...
           public void doSomething(){
               super.doSomething();
               //add functionality
           }
       }

In the code snippet above, the subclass is required to override the doSomething method to get the preferred result. The compiler will not let you know if this dependancy. Here is the correct way to do this:

       class super{
           ...
           public void doSomething(){
               //perform initialization
               addFunctionality();
           }
           public abstract void addFunctionality();
       }

       class sub extends super{
           ...
           public void addFunctionality(){
               //add functionality
           }
       }

This way, the sub class does not have to make a call to the super class' method and also the method 'addFunctionality()' is now required in the sub classes by the compiler

Programming

Anti-patterns that fall under this category are ones that deal with how the code is implemented rather than how the code fits together. Some examples of these patterns are Blind Faith, Law of Instrument, Cut and Paste, and God Object.

Blind Faith

Bild Faith occurs when a bug is fixed in a program but never tested before released. The programmer just assumes the fix will work so does not bother to test it. This can be detrimental if a bug did end up in the code that was "fixed" [8]. A solution to this problem is Test-Driven Development. In Test-Driven Development, the test cases are written before the code. This ensures that all code is tested and that Blind Faith can not occur [9].

Law of Instrument

THe Law of Instrument or golden hammer refers to the overuse of a good tool. The well known phrase "if all you have is a hammer, everything looks like a nail" is derived from this law. A good example of this would be a programmer writing all of his programs in the Java programming language. Java is a great tool but is not suited for writing all programs. The fix for this would be the opposite: Use the right tool for the job [10].

Cut and Paste

The Cut and Paste anti-pattern deals with the programmer cutting and pasting code from one section to another and then altering it. The problem with this is duplication of code. Although copy and paste seems like an easier and quicker way to add certain functionality to your program, it could end up making your code run slower. This pattern goes against the DRY principle. The refactored approach is to use a black box reuse design. Black Box reuse does not allow the user to change how the code is implemented. They can only interact with it the way it was intended [11].

God Object

This anti-pattern is when one class does too much. Classes and methods should only have one method or purpose. If it has more than that, it goes against the single responsibility principal. The solution to this is to refactor the code. Try and break up the code into the individual responsibilities and create new classes for them[12].

References

[1] http://c2.com/cgi/wiki?AntiPattern
[2] http://en.wikipedia.org/wiki/Anti-pattern
[3] http://en.wikipedia.org/wiki/Cash_cow
[4] http://en.wikipedia.org/wiki/Overengineering
[5] http://en.wikipedia.org/wiki/Software_bloat
[6] http://en.wikipedia.org/wiki/BaseBean
[7] http://en.wikipedia.org/wiki/Call_super
[8] http://en.wikipedia.org/wiki/Blind_faith_(computer_science)
[9] http://en.wikipedia.org/wiki/Test-driven_development
[10] http://en.wikipedia.org/wiki/Golden_hammer
[11] http://sourcemaking.com/antipatterns/cut-and-paste-programming
[12] http://blog.decayingcode.com/post/anti-pattern-god-object.aspx