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

Software design Anti- Pattern

Abstraction Inversion

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

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.

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 resuse 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.