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 pattern was 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]

Software design anti-patterns

Abstraction Inversion

Definition

Abstarction 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 indexer 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 w=equivalent functions, use them.
• Do not inject any weak constructs into the system.

Big ball of mud

Definition

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

Definition

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.

Object-oriented design anti-patterns

• Anaemic Domain Model

Separating the business logic from the Domain Model is termed as Anaemic 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 Anaemic Model is given below,

 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);
  }
 } 

Although, the above code looks right by providing segregation of data and service, its in violation of OOP principle of data and behaviour encapsulation.It could run into problems when there are muliple 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 practise 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. We can use delegation and create instance of Person class in Student class and utilize all the features of person class in Student class.

• CallSuper

CallSuper is a antipattern 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 practise because, in the future if the parent class's implementation changes it breaks the subclass too. And also it puts an additional responsiblity 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.

 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);
                                                                            }
 }                                                                        }