CSC/ECE 517 Fall 2011/ch7 7d df
DesignPatters
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, and anti-pattern is considered a bad solution to a problem. 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 outlines 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-patters 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 [1].
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 [2].
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 [3].
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 [4].
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 [5].
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 [6].
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" [7]. 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 [8].
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 [9].
References
[1] http://en.wikipedia.org/wiki/Anti-pattern
[2] http://en.wikipedia.org/wiki/Cash_cow
[3] http://en.wikipedia.org/wiki/Overengineering
[4] http://en.wikipedia.org/wiki/Software_bloat
[5] http://en.wikipedia.org/wiki/BaseBean
[6] http://en.wikipedia.org/wiki/Call_super
[7] http://en.wikipedia.org/wiki/Blind_faith_(computer_science)
[8] http://en.wikipedia.org/wiki/Test-driven_development
[9] http://en.wikipedia.org/wiki/Golden_hammer