CSC/ECE 517 Fall 2009/wiki3 1 kp

Anti-patterns

Overview

Anti-patterns is a type of design which when used may result in the code being unproductive and ineffective. It commonly describes a commonly occurring solution to a problem that may have negative consequences. There are many reasons as to why the anti-patterns were used,

• Lack of knowledge by the programmer who coded the system.
• Inexperience on the part of the programmer.
• Lack of proper understanding of the functionality the system needed to provide.

Anti-Patterns highlight the most common problems that face the software industry and provide the tools to enable you to recognize these problems and to determine their underlying causes.[1]

Known classifications

Some of the widely used anti-patterns are classified into the following categories,

• Organizational anti-patterns
• Project management anti-patterns
• Analysis anti-patterns
• Software design anti-patterns
• Configuration management anti-patterns
• Programming anti-patterns
• Methodological anti-patterns

Software design anti-patterns

Some of the important software design anti-patterns are,

Abstraction Inversion

Abstraction Inversion means implementing a lower level construct on top of high level constructs. A simple example would be suppose we have 2 constructs A and B. Let B be implemented on top of A but A is not exposed anywhere in the system and if we really require A then we end up building A on top of B and B was already implemented in terms of A. A short example of Abstraction Inversion is given below

• Example

The below code implements a set of binary values in a String which decide if it is true or false. (e.g. 'T' or 'F'). They then use the index to find the bit.

   char[] bitString ...;
   if (bitString[i] == 'T') { // do stuff

So in this case we have a character representing a bit value, but a character is nothing but a sequence of bits. Therefore we have a sequence made up of characters containing bits which are made up of a bit sequence.

• Solution
  • Choose the infrastructure carefully.
  • If the system offers equivalent functions, use them.
  • Do not inject any weak constructs into the system.

Big ball of mud

This term was coined by Brain Foote and Joseph Yoder's paper in 1999. This kind of anti pattern arises over a period of time where a number of programmers have worked on a system on various pieces of code. Dur to the lack of knowledge of the current systems the programmers write code which may have already been present and results in a lot of redundant code. Information being shared across the system which may result in it being globally declared and eventually making the code unreadable and unmanageable.

• Example

   float CalculateTotal(int quantity, float price){
      return quantity*price;
   }

   float CalculateAmount(int amt, float price){
      return amt*price;
   }

The above code shows two functions that perform the same function but was created which results in code redundancy and unreadable.

• Solution
  • Good understanding of the system prior to any major code changes.
  • Modularizing the code and defining the functionality at the proper location can help reduce the code redundancy.
  • Technical shifts(client-server to web based, file based to database based etc) can provide good reasons to create the system from scratch.

Race Hazard

A race hazard or a race condition is a flaw in the system where the output of the system depends on the order in which the system executes. This leads to inconsistency in the output. This term was coined with the idea of two signals racing each other to influence each other.

• Example

   global integer A = 0;
   //increments the value of A and prints "RX"
   // activated whenever an interrupt is received from the controller
   task Received()
   {
       A = A + 1
       print RX
   }

   //prints out only even numbers
   //is activated whenever an  interrupt is received from the serial controller
   task timeout()
   {
      if(A is divisible by 2)
      {
          print A
      }
   }

   Output would look like 
   0
   0
   0
   RX
   RX
   2
   RX
   RX
   4

• Solution
  • Mutexes can be used to address this problem in concurrent programming.

Magic Pushbutton

This is a very common anti-pattern that shows up on graphical user interfaces programming environments. The user first draws the user interface and then builds up the business logic in the automatically created methods. Some of the issues faced in this are,

• The code for in those defined functions grow large.
• Change in the user interface leads to a lot of changes in the functions and becomes difficult to manage.
• Testing becomes an issue.

• Example

Below is a bad example of Magic PushButton Anti Pattern.

   procedure TForm1.ButtonClick(Sender: TObject);
   var 
      reg:TRegistry;
   begin
      reg:TRegistry.Create;
   try
      reg.RootKey:= HKey_Current_User;
      if reg.OpenKey('\Software\mycompany',true) then
      begin
        reg.WriteString('Filename',edit1.text);
      end;
     finally
      reg.Free;
     end
   end

A good example of the same is given below. This is done by re-factoring the business logic. In the below example this is done by storing the file in an registry in a separate class.

   type
    TReference = class
    private  
      FFilename: string
      procedure SetFilename(const Value: string)
    public
      property Filename:string read FFilename write SetFilename;
      procedure Load;
      procedure Save;
    end

The above code will call Save method from the click handler.

   procedure TForm1.ButtonClick  (Sender: Object);
   begin
      Preference.Save;
   end;
   procedure TForm1.EditChange (Sender: TObject);
   begin
     Preferences.Filename:= edit1.text;
   end;

• Solution
  • Create functions and modularize the code as much as possible so that the code could be well maintained and flexible.

Object-oriented design anti-patterns

Some of the important Object-oriented design anti-patterns are,

Anemic Domain Model

Separating the business logic from the Domain Model is termed as Anemic Domain Model.One of the prime reason for it being popular is, it provides separation of logic and data. To site few places this is used are Java's Entity beans and .Net's three layered service application. A short example for Anemic Model is given below,

• Example

 class BankAccnt {
   private double balance;
   public void setBalance(double balance) {
   this.balance = balance;
 }  
 class AccntService {
   public void debit(Account account, double amount) {
   account.setBalance(account.getBalance() - amount);
  }
 } 

• Solution
  • Although, the above code looks right by providing segregation of data and service, its in violation of OOPs principle of data and behavior encapsulation.It could run into problems when there are multiple type of accounts and some of them have overdraft protection, then debit method has to manually check for account type.This can be corrected by moving the behaviour (debit method) into BankAccnt Class.

BaseBean

In the practice of BaseBean, subclasses are derived from an utility class, even though delegation is possible. Inheritance can be evil sometimes, either breaking some subclass due to change in parent class or very deep hierarchy of classes leading to confusion and no reuse of code. For example, if we want to create a student class and we already have person class, inheritance is not the right way to go.

• Solution
  • We can use delegation and create instance of Person class in Student class and utilize all the features of class Person in class Student.

CallSuper

CallSuper is a anti-pattern in which subclass overrides a parent's method and calls the parent's overridden method from the same method. This is considered as a bad practice because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsibility on the subclass's developer to call Super.The correct way to go about this is the parent class declaring a separate hook method for subclass to override.

• Example

 // Wrong Way                                                         // Correct Way
 public class EventHandle{                                             public class EventHandle{
   public void handle (BankingEvent e) {                                  public void handle (BankingEvent e) {
     cleanUp(e);                                                            cleanUp(e);
   }                                                                        doHandle(e);  //hook method
 }                                                                        }
 public class TransferEventHandler extends EventHandle{                   protected void doHandle(BankingEvent e) {
   public void handle(BankingEvent e) {                                   }
     super.handle(e);                                                     public class TransferEventHandler extends EventHandle{
     initiateTransfer(e);                                                   protected void doHandle(BankingEvent e) {
   }                                                                           initiateTransfer(e);
                                                                            }
 }                                                                        }

Conclusion

The significance of anti-patterns is the same as design patterns, anti-patterns are real helpful in identifying bad design.Thus the beforehand knowledge of anti-patterns comes in handy in making sure that the code base doesn't make use any of it. They should be identified at early stage of SDLC life cycle, because it might require significant effort to remove anti-patterns as you go down the SDLC life cycle.

See also

• Design Patterns
• Code Smell

References

• Abstraction Inversion
• Big Ball Of Mud
• Race Hazard
• Magic Pushbutton
• Anti-pattern
• Anemic Domain Model
• BaseBean

External Links

[1] AntiPattern
[2] http://www.antipatterns.com/
[3] http://c2.com/cgi/wiki?AntiPattern
[4] http://www.martinfowler.com/bliki/CallSuper.html
[5] AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J.Brown and Raphael C.Malveau